home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1996 #15
/
Monster Media Number 15 (Monster Media)(July 1996).ISO
/
pcboard
/
brv1b6.zip
/
BASERUN.DOC
next >
Wrap
Text File
|
1996-06-02
|
264KB
|
5,814 lines
┌─────┐ ┌──────┐ ┌───────┐ ┌─────┐ ┌─┐ ┌─┐ ┌──────┐ ┌──────┐ ┌─────┐ ┌──────┐
│ ┌─┐ │ │ ┌──┐ │ │ ┌┐ ┌┐ │ │ ┌─┐ │ │ │ │ │ └┐ ┌─┐ │ │ ┌──┐ │ └─┐ ┌─┘ │ ┌──┐ │
│ │ └─┘ │ │ │ │ │ ││ ││ │ │ └─┘ │ │ │ │ │ │ │ │ │ │ └──┘ │ │ │ │ └──┘ │
│ │ ┌─┐ │ │ │ │ │ │└─┘│ │ │ ┌───┘ │ │ │ │ │ │ │ │ │ ┌──┐ │ │ │ │ ┌──┐ │
│ └─┘ │ │ └──┘ │ │ │ │ │ │ │ │ └─┘ │ ┌┘ └─┘ │ │ │ │ │ │ │ │ │ │ │
└─────┘ └──────┘ └─┘ └─┘ └─┘ └─────┘ └──────┘ └─┘ └─┘ └─┘ └─┘ └─┘
┌─────┐ ┌─┐ ┌─┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌───────┐ ┌─────┐
│ ┌───┘ │ │ │ │ │ ┌───┘ └─┐ ┌─┘ │ ┌───┘ │ ┌┐ ┌┐ │ │ ┌───┘
│ └───┐ │ └─┘ │ │ └───┐ │ │ │ └─┐ │ ││ ││ │ │ └───┐
└───┐ │ └─┐ ┌─┘ └───┐ │ │ │ │ ┌─┘ │ │└─┘│ │ └───┐ │
┌───┘ │ │ │ ┌───┘ │ │ │ │ └───┐ │ │ │ │ ┌───┘ │
└─────┘ └─┘ └─────┘ └─┘ └─────┘ └─┘ └─┘ └─────┘
Base Runner, v1.o, Written by Steve Tupy
Copyright (C)1994-96 CompuData Systems
All Rights Reserved
─────────────────────────────────────────────────────────────────
WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
─────────────────────────────────────────────────────────────────
This program is NOT FREE. We support the shareware concept in
allowing you to try this program out , but FULLY expect you to
support us in making this program everything it can be. This is
something that CANNOT be done if you do not register the programs
you use! This is NOT an option! You are entitled to evaluate this
program for not more than 30 days at which time you are expected
to either delete it from your system(s) or register it.
─────────────────────────────────────────────────────────────────
Table of Contents
───────════──────
Introduction to Base Runner
features,echos,filebases,dist. package etc. 1.1.0
How does it work? 1.1.1
Describing Base Runners Filebase system
Layout,indexes,handling etc. 1.1.2
Describing concepts of File Ownership 1.1.3
What does it do?
Read Config, File Manager,Echo importation,
deletions, adoptions, file movement,
duplicate checking etc. 1.1.4
Other Considerations 1.1.5
File Area Links 1.1.6
System Requirements 1.1.7
Main Configuration 1.2.0
Paths,System Info,Global Options. 1.2.1
Inbound Directory,
Outbound Directory,
Netmail Directory,
Alternate Netmail Directory,
Filebase Directory,
Headers,
Log File,
Master File List,
Hatch Master List to?,
File Trash Can,
Node Address Trash Can,
Uplink List Directory,
Work Directory,
External Text Editor,
Magic File List,
CD ROM Drive List.
Global Options 1.2.2
BBS Name,
Sysop Name,
BBS Phone,
Location,
File Manager,
Duplicates to Bad Directory,
Duplicate Limits,
User Uploads,
Auto Uplink,
File System,
History Days,
HTML Style bulletin generation,
Video mode,
Time Zone,
Net Retry,
Retry Delay,
Text List,
PCB Netmail or *.MSG,
Auto Hatch,
Screen Blanker,
Minimum Drive Space,
Log Format.
Network Address' 1.2.3
Origin Lines 1.2.4
Virus Scanners 1.2.5
Compression Formats 1.2.6
Extension,
Stamp Offset,
Recursable?,
Extract1 Command line,
Extract2 Command line,
Add File(s),
Delete File(s),
Archive Comment,
Archive Conversion,
Archive Stamp.
File Folders 1.2.7
BrConfig DataBases 1.2.8
Node Information 1.2.9
Uplink Lists,
Auto Area Creation,
Auto Unlinking,
Addressing,
Sysop,
File Manager Password,
Folders,
Attach Flag,
Auto Create?,
Cloning File Areas,
Cloning Echo Areas,
Security,
Request to Message Base,
Kilobytes In,
Kilobytes Out,
Files In,
Files Out,
Daily KByte Cap,
Daily File Cap,
Unlinking,
File Manager Name,
Area Manager Netmail Status,
Maximum downlink archive size,
Advanced Tic,
Ticmode,
Archive Compression type.
File Area Configuration 1.2.10
File Area Name,
File Area Description,
File Directory,
BBS File Base,
Filebase Name,
Folders for this area,
User Uploading into System,
BBS Header,
BBS Footer,
Add Files,
Delete Files,
Zip Comments,
Maximum Files,
Delete Age,
Archive Conversion,
Virus Scanning,
Duplicate Checks,
Deletions,
Adoptions,
Uploads,
File Requestable,
System Wide Dupes,
Original Dates,
High Ascii,
Sort By,
Sort Order,
Convert to,
Security.
Importing from your PCB files areas 1.2.11
File Area Links 1.2.12
Custom Headers/Footers 1.2.13
Alt-G, File Areas Global Menu 1.2.14
Echo Area Configuration 1.2.15
Area Name,
Comment,
Folder,
Message Base,
Announcements,
Uploaded By,
Aka's,
Initial,
Owner,
Pass Thru,
Echo Out,
Description Options,
Origin Line,
Keep Requests,
Keep Receipts,
Announce,
Traffic,
Files In,
Files Out,
Bytes In,
Bytes Out,
Hatched Files,
Hatched Bytes,
Delete Tic File,
Delete Attach File,
No Delete,
Alt-G, Echo Areas Global Menu 1.2.16
A Note About Downlinking(Unlimited Downlinks) 1.2.17
Downlink and Hatching 1.3.0
Using BRConfig 1.3.1
BRUtil Utility Program 1.4.0
Using BRUtil
Pack FileBases, 1.4.1
Build Indexes, 1.4.2
Duplicates, 1.4.4
Dupe Trim, 1.4.5
Notify Lists, 1.4.6
Hatching Files, 1.4.7
Sending Files, 1.4.8
Init Bases, 1.4.9
Build CRC, 1.4.10
Auto Unlinking, 1.4.12
About Base Runner, 1.4.13
History+ 1.4.14
Dirs(DIR & Files.BBs Writes) 1.4.15
Exit to Dos 1.4.16
BREdit Filebase Editor 1.5.0
Requirements, 1.5.1
Initial List Dialog,
Command Summary 1.5.2
"Hot Spots",
Alt A - Add to File Id,
Abandoning Files,
Copying Files,
Deleting Files,
Editing Files,
File id file add,
File Hatching,
Area Info,
No Kill,
Moving Files,
No Show,
File Ownership,
Selecting Files,
Touching Filedates,
Viewing Files,
Exiting the program instantly,
Other Commands available.
Editing A File Entry. 1.5.3
BRFreq, Base Runners File Requesting System 1.6.0
Introduction
Description of what it does
Installation and Setup 1.6.1
Configuration 1.6.2
Path to Intro Screen
Path to Main Screen
Path to Bye Screen
Path to Help Screen
Screen Delays
Using BRFreq 1.6.3
Batch Editor,
System Selection,
Goodbye/Logoff,
Files Listings,
Help,
Quit to BBS,
Other considerations. 1.6.4
Requests from Other Systems.
Using Base Runner 1.7.0
Using the Area Manager 1.7.1
What went wrong? 1.7.2
Converting from Other Formats(Convert.exe) 1.7.3
What you get for registering. 1.7.4
ErrorLevels returned by Base Runner 1.7.5
Why use Base Runner? 1.7.6
Strategy 1.8.0
More Points Regarding File Movement 1.8.1
A Couple of Tricks. 1.8.2
User Support and Support Sites 1.9.0
Lets hear it for our Beta Team! 2.0.0
Files in the distribution archive 2.0.1
DataBase files maintained by Base Runner 2.0.2
1.1.0
Introduction
------------
Base Runner is a utility designed to completely self-maintain
every possible aspect of your PCBoard(or FILES.BBS) file system.
It does everything. And when I say everything, I mean EVERYTHING.
The program and its utilities cover such a broad range of features
that it is not advised that you just plug it in and walk away.
For brevity, any reference to Pcb DIR files can also be considerd
a reference to the commonly used FILES.BBS files that are used by
most BBS systems for their file area lists.
However, we designed it so that if there are certain features
you don't want to run, you can disable them easily enough. For
example, Base Runner covers all aspects of upload processing;
compression conversion, virus checking and so on. But if you
want to stick with your current upload processor then you can
disable any or all upload processing procedures as you choose.
Base Runner also fully covers anything to do with file echoes.
If you don't know what file echoes are there is a section
outlining them.In order to run the basics of Base Runner all you
need is PCBoard v14.x. If you want to run file echoes you'll
need a front end mail program like Front Door or D'Bridge and now
PCB even supports Fido mail processing.
And to even go further, Base Runner has a complete file request-
ing system which allows both your users a very handy door to use
to send requests back and forth between your system and others,
and also other Fido sysops who may be connected to your requesting
system as well. The door maintains batch ques, allows browsing the
file areas of various systems while being able simply "Flag" files
for requesting. Then the door automatically sends out the request
to the appropriate system. All of this with full accounting of all
file activity as well as configurable "Caps"(limits) on a node
per node basis.
It is also assumed that you know how PCBoard operates. As a
matter of fact you should be WELL versed on how the PCBoard file
system works; DIR files and so on. Like I said this is not a
plug and play utility. It will require some thought as to how
you set the system up. But once set up, the amount of time
you'll spend maintaining your file system will be almost zero.
No matter how a file enters your file system Base Runner will know
about it and look after it for you.
So what does it do.Since the scope of Base Runner is so large,
it is best to first describe how it operates and the basic
principles behind its operation and that's what we'll get into
right off.
1.1.1
How does it work?
-----------------
First, think of how your PCBoard file system works. You have a
number of sub-directories with files in them for download by
users. The main central reference to these files are the PCBoard
DIR files; the text files that hold the file names, dates, sizes
and descriptions. When using PCBFiler to manage your file areas,
the DIR files are the main reference to the contents of each file
area.
Base Runner changes this outlook. When you install Base Runner,
you run a procedure that reads all of your PCBoard DIR files and
creates a set of databases that reflect their contents. As of
this point, your DIR files are NOT the central reference to your
file areas.The Base Runner databases now are. This makes PCBFiler
obsolete. You won't use it anymore. Instead, you'll use the
included utility, Bredit. It performs the same functions as
PCBFiler plus many more. We knew it might be painful giving up
PCBFiler so we had to provide something better; and we did. For
FILES.BBS systems, this now offers a new editor for your use that
will allow you to move,copy,delete,touch,view,hatch or do various
other operations on your file areas.
When Base Runner goes through its processes, the last thing it
does is write an entirely new set of DIR files based on what's in
the Base Runner databases. (filebases we'll call them) So now, a
file area can be described as something that contains 3 elements:
A sub-directory with files in it.
A filebase (Base Runner database) as a central reference.
A PCBoard DIR file(or FILES.BBS)
The PCBoard DIR files are now a reflection of the Base Runner
system. By now you're probably thinking, "But how do I look after
<blank> now?". You don't. Base Runner does. Your DIR(or FILES.BBS)
files are regenerated any time you run Base Runner. If you change
them manually, any changes made with an outside utility will be
lost. This is why Base Runner does everything you can think of. If
nothing else can touch your file system then Base Runner had
better be good! And it is.
1.1.2
FileBases
---------
In order to better understand how to maintain your filebases,
it's best to understand just how filebases work. In main
configuration you give each file area the filename of the
filebase. For example, say you have a file area called New
Uploads. You might name the filebase "NEWUP". In this case,
Base Runner will create:
NEWUP.IDX - Filebase index FILEBASEDIR\IDX\NEWUP.IDX
NEWUP.HDR - Filebase data header FILEBASEDIR\HDR\NEWUP.HDR
NEWUP.TXT - Filebase text FILEBASEDIR\TXT\NEWUP.TXT
The following is what is contained in each of these files:
NEWUP.IDX:
Filename - Name of a given file
Filedate - Date of a given file
Status - Status; deleted, etc.
Offset - Where in NEWUP.FBS the main information starts
NEWUP.HDR:
Areaname - Name of the file area to which this file belongs
Filename - Filename of this file
Size - Size in bytes of this file
Date - Date of this file
Index - Where the file description starts for this file
Length - Length in bytes of the file description
CRC - CRC32 of this file
ID - An identifying marker to aid in synchronization of
corrupted filebases.
Uploader - Person who uploaded this file.
UL Date - Date of upload(if uploaded) of this file.
Times DL - How many times has this file been downloaded.
Last DL - Last date of download of this file(for future use).
NEWUP.TXT:
Line per line, not wider than 45 characters in PCB mode and not
more than 60 characters in FILES.BBS mode, the text that goes
into the description.
There is one record for every file in both the IDX and HDR
file. So if your new upload area has 200 files in it, each of
these files will have 200 records. Each record contains the same
information as your PCBoard DIR file(s) plus a bit more. You
don't have to worry about the exact structure here, just the
basics of what's involved.
So what Base Runner does is maintains these databases, and the
files associated with each record in the database. If a file
shows up in a file area that Base Runner doesn't know about,
Base Runner adopts the file and all of the above information
automatically.If you kill a file off manually,Base Runner removes
the record.
When Base Runner processes a file area it loads the index file
into memory entirely. This is a very small index record (only
23 bytes) and since all available memory is used, the only limit
to the size of your databases is your available memory. Please
note though, that a comparitive ratio IS held in conventional(the
indexes are also indexed in a manner of speaking) memory, so you
will see SOME conventional memory loss in VERY large filebases.
Because it loads the entire index into memory, Base Runner is
unbelievably fast considering what it does. If you enable every
feature there is, basic maintenance takes seconds on even the
largest area.
How this is done is as follows. Only 20 bytes of the index are
loaded at any one time. For each record, 2 bytes are held in what
is known as conventional memory, memory below 1 meg, and the rest
are thrown into pages in upper or extended memory if such memory
exists. Failing that, conventional memory is used. Even if you
are using total conventional memory of one meg you can load up a
database of approximately 35,000 records per area. Assuming that
this is attached to one DOS directory and that all the files are
in that directory, DOS would break before Base Runner would. This
kind of power is hard to come by these days.
It may seem complicated but the complexity is handled by
Base Runner. You now know roughly how the databases are managed
and that's all you really need to know as far as the details go.
The rest is configuration. You should also start to consider
this new "view" of having seperate files areas and echo areas as
this whole package revolves around those two levels of
operation and their interaction with each other.
1.1.3
Ownership
---------
As you may have noticed in the previous section, a filebase
record holds the name of the file area to which a given file
belongs. This is referred to as file ownership. In other words,
when looking at a given file, that field answers the question "to
which file area does this file belong?".
When you configure your file areas (which we'll get into
shortly) each file area must have a unique name. You pick the
name, it doesn't matter what it's called. But something notable
would help like NEW_UPLOADS or NEWUP90 or IBM_GAMES. As long as
it's one word and is unique.
Base Runner supports fully qualified automatic file movement.
Each individual file on your system knows what area it's owned by
or belongs to, even if it's in a different area. So although
CHESS.ZIP may reside in NEW_UPLOADS, it actually belongs to, or
is owned by IBM_GAMES.
You can configure each file area to move the files it contains
based on a number of days. For example, you could have
NEW_UPLOADS move any files older than 30 days somewhere else.
But where?
Base Runner gives you 3 options. One is "Nowhere".Files stay in
a given area for good. The second is to any other defined file
area. The third is "Home". If a file area is set to move files
Home after XX days, files older than XX days are moved to the
area that owns them. A new upload area is perfect for this
because any files older than the number of days you specify are
moved to where they belong automatically.
Needless to say, considerable thought should go into how your
files system is configured. Like where you would normally move
files manually. Base Runner was designed for maximum flexibility
when it comes to how file areas are handled. User uploads are
detected and imported automatically. If you want an off-line
area, create one and tell all your files areas to move files
there after 6 months or a year old.
So when initially configuring Base Runner, keep this in mind
because it's a crucial part of how Base Runner operates and how it
will manage your system. The other included utilities provide
maintenance and manual control over ownership also. If you would
like some input as to how some of us(the beta team) have had it
set up, please consult the document STRATEGY.DOC.
1.1.4
What Does It Do?
----------------
You'll get a better understanding of what Base Runner does from
a list of its operational order. Remember that the things listed
below are fully documented later on and that most of the
individual functions listed here can be disabled or changed in
configuration or from the command line.
- Automatically Maintains Your Uplinks Lists
------------------------------------------
Early on in Base Runners execution, your inbound area is
scanned for a match against your uplink lists, if any, in your
nodes configuration to see if one of the files listed in your
nodes base matches a file that is currently in your inbound
directory. If a match is found, we assume it is a newly updated
uplink list and we copy it to the uplink list directory
configured in BRCONFIG. It is logged and reported to the screen.
This way you are always up to date with your uplink lists and
never have to maintain or "copy them" over to your Base Runner
uplink list directory. These lists are used for your downlinks
when they try to request echo areas from you that you don't
currently have online. Your copy of Base Runner will scan these
lists and if the uplink is connected to the same Folder(or group)
as the downlink, a request is made to the uplink to get the area
for your downlink. During this time, if configured, an echo
area and/or a file area are created to accomodate this new
areaname so that you are now ready to route files through to
this downlink node.
This feature has a second phase to it. Since you are getting
these lists, why not put them to good use? Base Runner will go
through your echo areas and update their descriptions with the
new .NA or .NO files descriptions. Only .NA and .NO files are
supported at this time. This is especially handy if you are a
large hub and have many areas to manage.
- Area Manager
------------
The file manager checks for any netmail messages addressed to
it and processes them accordingly. This function is used for
remote maintenance of the file echo areas any system may receive
from you. This offers your downlinks(if you are a hub) an easy
way of adding or deleting (as well as many other various
operations available) echo areas automatically by remote
netmail. This makes your file management system virtually
maintenance free!
- Automatically Maintains Outbound Que
------------------------------------
Base Runner looks at the Outbound Que(if PCB, or netmail
directory) and checks for sent files and removes them from the
outbound directory. This only applies to files move to the
outbound area for downlinking, not those that were originals.
They were attached from their home filebase so they are simply
"unfrozen"(via the utility programs NOKILL maintenance
operations) so that now regular filebase operations take effect.
- File Echo Importation
---------------------
The inbound directory is checked for new .TIC files and
possible attached files. If any, they are imported to the system
as you have defined. During this time the files may be imported
to your filebases. If this occurs(if the area is not passthru),
certain operations are performed on the file. For example, if
the file is to be converted to an alternate archive type, it
will first be extracted into your work directory(preserving all
the original archives path information and any imbedded archives)
after which it may undergo such tests as CRC,3 level duplicate
detection,Add files, delete files, change/add comments, 2 way
file id etc. File movement defaults are set up as well as other
system info and the file is imported into your filebase for that
echo. Full downlinking is supported with unlimited downlinking.
- Deletions
---------
Each Base Runner filebase is loaded up and compared to what's on
disk. Any files that exist in the filebase but don't exist on
disk are removed from the filebase. This ensures the filebase is
kept up to date on missing files.
- Age Deletions
-------------
As above, but the file is checked for age against the
specified number of days set in the configuration for this area.
If this area is set to zero, then no age deletions take place
for this area. Each area is checked in your database.
- Adoptions
---------
Again the filebases are compared against their associated
directories but this time if a file exists on disk that doesn't
exist in the filebase (an orphan) , it is adopted as a orphan
file and processed just as an imported echo file is. That is to
say that it falls under all the same testing as does the echo
files imported such as Virus Scanning,CRC test, Add Files, Delete
Files, Comments, 3-Way Duplicate scanning, 2-Way File id
insertion etc. Finally, it is imported into the filebase and a
new DIR file(or Files.bbs) is regenerated for the area.
- File Movement
-------------
Files are automatically moved between areas based on the area
links you define in configuration. More on this in the next
section.
- Duplicate Checking
------------------
Filebases are checked for lines that duplicate themselves in
the filebase. Dupe checking of the file is performed at any
point a file can enter the Base Runner system.
- User Upload Processing
----------------------
If a filename is found in a DIR file(or Files.bbs) and exists
on the hard drive directory specified for that area, it is
considered a user upload and processed into the system. Because
we assume most systems already have a valid upload
scanner(SpotChek by CompuData Systems is a popular one) and that
the file has already undergone rigorous testing, we only do a
minimum amount of testing on these files including CRC,
duplicates, validation, archive stamp checking etc. These files
are then imported into your filebase but a new DIR file is not
generated as it is already in the DIR file(or Files.bbs).
- Filebase Sort
-------------
Filebases are sorted according to the sort order specified in
file area configuration.
- User Requests are Processed
---------------------------
These are the requests users from other systems(who are
involved in a request system with you) that must be filled. Of
course the usual security checks are made to make sure this node
is indeed authorized to take these files and that their limits
have not yet been reached, but otherwise, a return attach file
is sent to the requesting system. If the file is not found or
fails for some reason, both you and the requesting sysop are
notified of the problem so that you may sort it out later.
New List updates and complete list generation are also handled
during this operation as well as incomming files that your users
may have requested from other systems.
- DIR File Generation ( or FILES.BBS )
------------------------------------
For those filebases that have changed,Base Runner regenerates the
associated PCBoard DIR file. For this reason, changes made to
the original listing file such as with PCBFiler may not apply.
Functions performed with such utilities are done to the Base Runner
filebases directly with the included utility, Bredit. It does
everything the above programs do and lots more; a nice piece of
work.
- TrashCan File
-------------
A textfile containing one filename per line of a node address
which is considered to be "trash" or unacceptable. If this option
is set to "on", all files from that node will sit in the inbound
and not be processed. Also, this node address will not be added
into the nodes database. This will be logged so you can monitor or
add the node manually if you wish at a later date.
Base Runner was designed in a very modular way, so these above
functions plus many more can be enabled or configured through
main configuration. Each file area on your system can be handled
differently, as well as the files that enter into them.
The thing you have to remember is that once you define one of
your file areas under Base Runner it belongs to Base Runner.
Manipulation of the resultant DIR file directly is possible but
may not be desirable. Deletion checking and Adoptions will keep
the filebase updated but what's in the DIR file is a perishable
reflection of Base Runner's filebases.
You don't have to surrender your entire system, you can include
only those areas you wish Base Runner to look after. We put a lot
of flexibility into the program so you're not tied to doing a lot
of things you don't want. If one day you decide not to run it
anymore, just stop using it. Your DIR files will continue on
without Base Runner present.
- Bad Files Area
--------------
At various times during Base Runners execution, there may be
times when certain files fail the operations performed on them
for whatever reason. This is the time that Base Runner(if set up
for it) may move these files to an area that is hard coded
called "BAD_FILES". This area is automatically created by the
configuration program if no files area database exists and uses
certain defaults but you may change them if you like. The
directory and specific DIR file(or Files.bbs) are also updated
by this areas regular functions. This area is exempt from all
file movement operations by default. It is also exempt from all
deltions or any other scanning usually performed on the regular
areas files. The reason for this is that we must assume that the
file is either corrupt or not a file we can work with or it
would not be here at all, so we must not touch it until you or
one of your co sysops does something with it. This area is set
up and its parameters established at start up and if it is not
valid, Base Runner will bark up and refuse to run, logging the
error as well as showing you on your screen.
- Automatically Maintains your History File
-----------------------------------------
There is a small file that records all files coming in and out
of your system. This "History" file has alot of information
about exactly what the file did when it went through. With this
information, extensive bulletins can be generated(please read
BRUTIL) to report statistical records of your systems file
activity. The file simply keeps growing if it is not maintained,
so if the number of "historydays" in your configuration is a
value other than zero(zero denotes unlimited size) the file is
scanned back to the number of days so that it stays "manageable"
on your hard drive.
1.1.5
Other Considerations
--------------------
The design of Base Runner took into consideration that you might
not want to just hand over your entire file system to a maniac
utility. I have a couple of areas on my BBS that are not touched
by Base Runner. I use the usual PCBoard ways of managing those
areas.
When you define a file area under Base Runner, any maintenance
outside of Base Runner is not encouraged.What I mean is, if you
have Base Runner looking after new uploads, and you go in with
PCBFiler and kill, move, etc.,Base Runner doesn't know about it.
But it's not a disaster. First, Base Runner does (optional)checks
and deletes filebase entries for non-existent files (ones you
killed) and adopts files that just appear (ones you copied in).
Base Runner comes with Bredit, a FULL featured file base editor
like PCBFiler but LOADED with features for manual updating of
your file areas if needed. Movement should be automatic, but
some things need changing like file ownership as described
earlier.
If you don't want certain areas managed by Base Runner don't
define them as a file area. No problem. It's left alone and you
can use PCBFiler to look after those manually.
If you want to run Base Runner strictly for the file echoes, you
must define at least one file area. It can be one or more
private to the BBS areas, also defined in your BBS setup. Since
Base Runner reflects its system with a DIR file,files can be moved
around the old fashioned way.
The only weakness in all this is user uploads. We identify a
user upload as a file that exists in both the DIR file and on
disk,but does not exist in the Base Runner filebase.It is adopted
and ownership is assigned to the area it was adopted in. We
would like to have the ownership set automatic but there's
nothing to tell us what area a file would belong to. This is the
small manual maintenance required.
You can define an upload area under Base Runner and set it to
move files to your new upload area after 1 day. Use Bredit to
assign the new file's ownership and run Base Runner.Automatic file
movement will take over provided you have it set right. Of course
these are only examples and are not meant to say this is how you
must run it. Please consult the file STRATEGY.DOC for some info on
different ways to set up your file/echo areas.
Also something to consider is that this package is not
crippled nor 'rated' in levels of advancement. We do not insist
on "advanced" tic modes to have Base Runner include such things
as LDesc in generated TIC files. As such, all the power
available to you is right there in front of you.
It has been asked if Base Runner will scan message bases for
certain files requested and reply based on those requests. This
is a feature of a BBS and Front Ends such as Front Door and is
not within the scope of Base Runner, nor should it be. That not
only serves to confuse but also adds unnecessary overhead. What
length has been offered, however, is that there is a user
request system that allows users to request files from other
systems directly.
Base Runner is not provided for 30 days and you are NOT
required to register it to continue using it. There are very few
features offered to registered users which make life easier but
not unbearable. Base Runner may be used indefinately without a
license in its present form. Evaluate it for as long as you
like. If you think that some of the registered features suit
you, then consider registering it, that is up to you. So you see
we are not money grubbing hogs but a group of concerned sysops
who would like to offer a better level of TIC/File processing
that is within reach of all sysops. We know how hard it is to
run a system without getting nailed for every piece of software
you run online in order to maintain your system. With that we do
ask one small favor of you. Please let us know how you like the
software and if you wish to see something added or changed. If
you see something that is not working properly, please contact
us, don't be shy, we are more than glad to help and if indeed
what you find is more than a configuration problem, we will
endeavor to develop the product to your level of satisfaction.
1.1.6
File Area Links
---------------
As mentioned,a file area in Base Runner is much the same as a
file area on your BBS. The difference is, Base Runner file areas
have names. Any old name that makes sense, as long as its
unique. If you're used to file echoes, they employ the same
thing but this has nothing to do with file echoes.
Each file area you define allows you to configure two things
about files entering that area:
1 - Initial area for uploads
----------------------------
Files uploaded to this area (assigned ownership) are to be
placed in the specified area. So files uploaded to ZIP_UTILITY
could be initially placed in NEW_UPLOADS.
2 - Move Files to Which Area
----------------------------
There are 3 main choices here. 1) Nowhere. Files are here,
and move nowhere, even if they are owned by other areas. 2)
Home. Files are moved to the areas that own them. 3) Specified
area. You can specify that files in this area are moved to
another area. Like, NEWUP30 configured to move files to NEWUP60
after 30 days.
As you can see, based on this per area configuration, you can
define chains of areas linked together that files follow. Like
from UNTESTED to NEWUP30 to NEWUP60 to HOME and then deleted
after 6 months if you want.
The key to the accurate flow of new incoming files is how they
are handled when they enter the Base Runner system.There are 4
ways:
1) File Echoes
2) User Upload
3) Local Upload
4) File Adoption
File echoes are covered later, but ownership is looked after
quite nicely by itself. User upload is based on the possibility
that the user is an idiot, and needs a life badly. Meaning, its
a wide open door as far as error is concerned. This is where the
ability to change file ownerships in Bredit comes in handy.
Local upload is YOUR fault. :^) When Base Runner adopts a file
(one on disk but not in the filebase) ownership defaults to the
area it was found in.
1.1.7
System Requirements and using SHARE.EXE
---------------------------------------
There are only a couple of things you should be concerned about
when considering the operation of Base Runner. You should have at
least a 80386 processor as the code is optimized to omit code to
support anything less than a 386 system.
At least 512K of ram is required but is not totally used unless
you have large filebases(greater than 65,000 files). This allows
the speed necessary to optimally run systems that deal with such
large amounts of data. If you run out of memory, the disk is used
to swap memory in and out but is strongly recommended against as
the thrashing on your drives may be intolerable and will result
in a major speed loss.
File sharing and record locking is used all throughout the code
so it is absolutely necessary that you run a program called SHARE
during your startup batch files.If you do not know anything about
this program or its use,please consult your DOS documentation for
more details.This is to accomodate PCB's configuration files that
are read and written to often. Running SHARE.EXE is as simple as
including the line SHARE.EXE in your autoexec.bat file but is good
to know what it is and why you are running it.
It is also absolutely necessary to have a valid FIDO address or
this software is useless to you for any FIDO processing. Even the
file requesting system, since the rest of it depends on it, also
uses the FIDO standard as its interface. Base Runner will also,
if configured, use PCB's netmail conference area instead of some
other front end such as Front Door or D'Bridge, which use the MSG
format. Either format is supported.
The executable files are not very large, approximately 2.0 meg
in size.You may not use a program such as PKLITE or LZEXE to make
these programs smaller as they are overlaid for memory use. The
reason for this is they are heavily overlaid. These code segments
are calculated very carefully and if they are comressed,it messes
up the whole virtual data tables in the executable. Unpredictable
results will no doubt come your way in such a case,if the program
will even run at all!
The total size for an average system carrying 100 areas would
apprximately total 2 to 2.5 megs of hard drive space. Not bad for
what you are about see it doing.
1.2.0
Main Configuration
------------------
This section deals with the main Base Runner setup and file area
management. It also includes information pertaining to file
echoes. If you don't run any, the options for them are
inconsequential. If you do, you should be familiar with the
operation of a Fido front end mailer and its terminology.
Main configuration is a program called BrConfig.EXE. It is a
menu driven program with help at any menu or prompt with a press
of F1. It takes no command line parameters, nor does the main
program, Base Runner.EXE. The operation of the main program is
solely dependent on the contents of the data files maintained by
BrConfig.Therefore, BE SURE you have Base Runner configured right
before you run it!
If no configuration file is found in the directory you are run-
ning Base Runner from, a default file will be created. Along with
this, Base Runner will create a couple of directories for you so
that you will be all ready to run right away. The config program
will also create a new BAD_FILES file area, an area which is very
important for all of Base Runners processes.
If you have an existing system using another package, be sure
to check that program to see if it supports your processor type.
If it does(such as Allfix), you may choose to have it convert the
configuration over to Base Runners format before you run the con-
fig program. That way the files will be set up for you leaving you
with a minimum amount of work!
The main menu of BrConfig will appear and we'll start at the
top and work down. Base Runner has MANY features and they will be
covered as configuration is reached for them. First selection,
System Info presents a sub menu with four options:
1.2.1
System Info - Paths/Files
-------------------------
- Inbound Directory
-----------------
This is the path where inbound file echo files are stored. It
is typically your front end mailer's Inbound directory.
- Outbound Directory
------------------
This is where Base Runner will store outbound file echo files
and information. It is best that this directory be one that is
unique to Base Runner and NOT the same as the inbound path or you
will lose files. No other files can reside in this directory
except the ones Base Runner is downlinking. Failing to move files
out of this directory may result in them being automatically
deleted as part of regular maintenance.
- Netmail Directory
-----------------
This is the path where netmail messages are stored. It is
typically the same directory as your front end mailer's netmail
directory.
- Net Out
-------
Alternate directory to place outbound netmail attaches. If
this field is blank, it is ignored, otherwise this directory is
used instead of the above directory. This is handy if you would
like to temporarily output message attaches to an alternate
directory.
- Filebase Directory
------------------
This is the directory where Base Runner's file databases are to
be stored. Usually \DBASE\FILEBASE, since many file areas can add
up to a lot of files, keeping these separate maintains
organization. This will only be a head directory. The actual
directories that hold the bases will be under this one and will
be called IDX,HDR and TXT.
- Headers
-------
Base Runner gives you the option of using DIR File headers and
footers. They are, headers and footers at the top and bottom of
the directory listings the user sees. Using PCBoard, Base Runner
keeps these headers and footers in separate files. PCBFiler will
trash the headers if they're included in the DIR file itself.
This directory specifies where the individual header and footer
files are stored when Base Runner generates them. Please do not
confuse this with the path/filename of each header/footer in the
file area configuration. They are to allow you to place the orig-
nals whereever you like. This field is where all the new created
headers/footers will be. You should not keep the originals in this
directory.
- Embedded Directory
------------------
This is a temporary directory to store embedded archives, ones
in which archives exist inside other archives. This directory will
be used to store these files that extracted from these embedded
archives. The reason the regular work directory is not used is so
we do not tamper with the original archives directories. This aids
in the archive conversions where all original paths and sub dirs
are preserved.
- Log File
--------
This is the path and filename of the log file that Base Runner
generates during its operation. Although you can use an existing
log file used by another program,its best to let Base Runner
manage its own. Pressing F2 will invoke your external text
editor(if configured below) so that you may see and edit this
file.
- File List
---------
This option specifies where the master file list will be
placed. See the option under "Global Options" for further
information. This list should not have an extension as one will be
added automatically(ZIP).
- Hatch To?
---------
The echo area tag the master list will be hatched out to. You
may disable this feature by simply leaving this field blank. If
not blank, the echo area is searched for in your echo database and
if found, any nodes attached to that echo will recieve a copy of
the master list along with the necessary tic file so that they may
import the file just as any other file(and possibly downlink it
themselves).
- FTrashCan List
--------------
Path and Name of a text file used as a File Trash Can. This is
a plain vanilla text file with one filename per line, wildcards
accepted, of the list of files you will NOT accept on your
system. Please note that this is ignored by the echo modules
because it is assumed that your downlinks may still want the
file, so it is echoed out as usual. Pressing F2 will invoke the
external text editor(if configured) so that you may edit it
directly from the config program.
- NTrashCan List
--------------
This is a text list of nodes you wish NOT added during auto node
add. One node per line, you may use wildcards ...
1:229/428 These are all valid entries.
1:229/*
1:*
if no zone is specified, your main aka zone is used by default.
You may press F2 to edit this file directly if you have
configured the external text editor(please see below).
- Uplink Lists Directory
----------------------
A path to a directory where Base Runner will maintain its uplink
lists in. This is the path where new updates of your uplinks lists
will be kept. Up to 15 lists per node may be specified. All of the
lists will be in this directory. If you are not hubbing, this will
not be of any consequence to you.
- Work Directory
--------------
Base Runner needs a unique directory for storing temporary
files. It can be anything like C:\BASERUN but nothing else should
use it as Base Runner frequently deletes this entire directory and
everything below it(because the archivers sometimes create sub-
directories). Please make sure there are no sub directories to
this one.
- External Editor
---------------
This is the name of the program you wish to use as an editor
for the files descriptions. There is one built into BREDIT, but
this may give you more of what you want. We know how people can
get attached to "their" text editors so we offered this feature.
Of course you can still use the built in one by pressing enter,
but pressing F2 in the edit window will pop up your editor
instead. We have tried to test this with as many editors as we
could and found a problem with some(like DOS' edit for example)
of the editors. The reasons for this are as varied as the
editors themselves. In an effort to be as compliant as possbile,
we have attempted to have BREDIT run with the widest possible
width of editors on the market. If it simply resets the font and
then sets it back, the shell to the editor failed and control
was returned to BREDIT. In this case you may either use the
built in one or find another editor. We have had good luck with
the program called QEDIT here. Qedit is a program which requires
certain things in order for you to run it, so please consult any
documentation in regards to that or any other product.
- Magic File List
---------------
Path and Name of your Magic File list. This is a list with a
particular format in the form <MAGICNAME> -whitespace- <FILE>.
MagicName is the actual magic name that is scanned for. File is
the file(s) that will be used (wildcards permitted) for the file
translation so that all files matching this filespec will be
sent out as a file request. This is usually also used by most
front end mailers but is primarily designed for use with BRFreq's
file requesting system.
- CD Drives
---------
These are the drive letters of your configured CDROM drives.
Only the character letter of the drive is necessary. Base Runner
checks all drives for available disk space and cross references
these against your minimum setting to see if files may be moved
or copied there but also serves as a system for recording your
CDROM drives as well. Example...
"EKI" .. would mean that drives E, K and I are all CDROM drives
and that Base Runner should not try to perform any copies or
moves to those areas.
- Ann. Dir(Announce Directory)
----------------------------
This is an alternate packet directory for announcements.
Normally, when an announcement is created, it is appended to a
packet that originates from the node who sent you the file for
which that announcement is being made. There are times, however,
when you will want to place these packets into another
directory (secure directory for example). If nothing is entered
into this field, then inbound directory is assumed.
1.2.2
Systeminfo - Global/System Information
--------------------------------------
This is general information, mostly for use on reports and so
on. Their use will be shown in later spots, but the info
required is basic. DIR file headers and footers can use this
info, as well as notify reports for file echo operation.
- BBS Name - Name of your BBS; "Steve's BBS"
- Sysop Name - Your Name. A toughie.
- Phone - Your phone number.
- Location - City, etc... eg. Oshawa ON Canada
- Area Mgr?(or File Mgr)?
-----------------------
Should Base Runner perform Area Manager operations? Even if
this is set to "Y"es you can disable it via the command line
switch "NOMGR". Read Section on Area Manager for more info on
Area Manager activities.
- Move Duplicates to BAD?
-----------------------
Base Runner treats the file area named "BAD_FILES" as a special
area. If it exists, certain functions of Base Runner such as
duplicate checking move duplicate files to the file area
"BAD_FILES". If the file area doesn't exist, duplicates are
deleted. "Y" here indicates you want duplicate files move to the
BAD area. Otherwise, duplicates are deleted.
- Duplicate Limit
---------------
Base Runner maintains a file internally called BRDUPE.DAT. It
holds the CRC values of the most recent files entering the
system. If a new file via user upload, file echo, adoption etc.
enters the system and has a CRC value that matches one in the
duplicate base, it is considered a duplicate and dealt with as
per the above option.
This option specifies how many files to maintain in the
duplicate base. BrUtil has a function that packs the dupe base
to say 10,000 files if that's what you specify. That amount
would be average since the larger this number, the larger the
duplicate base.
- User Uploads?
-------------
This is the system wide toggle for disabling the User Upload
operations(registered).
- Add Node?
---------
This tells us whether you want Base Runner to automatically
add nodes to your database as they are encountered. Beware of
the security implications of this type of move. To help you with
security, Base Runner maintains a list of "trashcan" nodes that
it will not relate to in any way.
- Auto Uplink?
------------
Should Base Runner automatically search for uplinks and their
lists to connect a new echo area request? This applies to Area
Manager operations where a node has requested an echoarea which
is not currently in your database. You can have Base Runner
automatically generate a request to your uplink to connect
you(as well as the requesting node) and your downlink to the new
area. This area is created and added to your database so you are
then ready for new files moving in and out of that area.
- File Sys.
---------
A two item menu with either PCB or FILES.BBS choices on it.
Both formats are fully supported and maintained. PCB DIR files
are the ones most commonly referred to in this manual and are
the standard file used for PCB's file system. Files.BBS, on the
other hand, is a much more widely used format by a number of
popular BBS's. These have a very similar format but are
certainly not the same in the BBS's operations, so make sure
your system supports either of these types.
- History Days
------------
Number of days that will be kept and maintained in the history
file, BASERUN.HIS. This number will be the number of days that
Base Runner will go back in its history reports and is also the
way Base Runner calculates how much of the file to trim if it
needs it. This information is used for posting to messages or to
a text file or to a bulletin.
- HTML Bull
---------
The reports generated by Base Runner come in two flavors. One is
the obvious flat text that everyone is so used to and is the
fastest in execution(by a millisecond or so). HTML is a style of
report which uses special control strings to tell the HTML server
how to format the text, font sizes,lists etc...This aids in almost
giving your reports a World Wide Web appearance and can actually
be used as part of Web Pages.
- Video Mode
----------
Here you have 3 choices for video modes. With this set up you no
longer need to enter it on the command line. Please note though
that the command line will override your current configuration
setup. The 3 choices you have are...
1 - Quiet : This will run the main Base Runner program in what we
call stdout mode or flat grey mono mode with no boxes
or fancy fonts and no 16 color ega palette either.
This is handy for unattended mode or if your current
setup is not working in the higher resolution well.
We endeavor to be as compatible with as many systems
as possible, but it quite often happens that our
current VGA routines may not be compatible with your
particular video card.
2 - EGA : This will run in 16 color standard EGA mode. You will
get the boxes in color, but not the fancy fonts. They
are only available in VGA mode.
3 - VGA : This is the fanciest output there is, with 256 color
palette and specialized fonts. Not all systems can
run this mode successfully in which case you should
shift down to one of the lower modes.
- Time Zone
---------
The TIC standard requires a time zone. F2 will present a list
of time zones for you to choose from if you're not sure. It's a
3 character value that would contain something like EST, PST,
etc.
- Net Retry
---------
Base Runner supports networks and with networks come possible
clashes with file sharing.If Base Runner tries to access a file on
a network currently being modified by something else like
PCBoard,this specifies the number of times Base Runner will retry
the file before giving up. A value of 0 says forever.
- Retry Delay
-----------
This option specifies the delay between the above number of
retries on locked network files. 0 means no delay.
- Text List?
----------
Base Runner supports a master file list function. So many BBS's
distribute a master file list as one huge text file. What's
anybody going to do with a 4 meg text file? So Base Runner will
generate one of 2 types of a master file list. Specifying "Y"
here will have a separate text file for each defined file area
zipped up into the file you specified in Paths/Filenames.
If you say "N", Base Runner will generate its own format of file
listing, and attach the viewer (BRVIEW.EXE) along with it. This
way the user has a manageable utility (a scaled down Bredit) to
view, print or export the file list. The list is generated by a
function under BrUtil.
- PCB Net?
--------
There are currently three types of netmail handling for Base
Runner. The first most commonly used one is the *.MSG format
used by many popular front ends and BBS's. The second and third,
which are broken down only by whether or not your PCB version is
15.21 or later. 15.21 has a unique outbound QUE file that must
be treated differently. This QUE file as well as some other
subtle changes are the only differences in these choices,
otherwise, you will still need to use the *.MSG handling that
PCB offers in order to properly use Base Runner. Please consult
your PCB documentation for more details on how to properly
implement the FIDO capabilities of your PCB system. The only
time you won't need one of the PCB netmail toggles is when you
do not run PCB at all.
- Auto Hatch?
-----------
This tells Base Runner if it should automatically hatch out
new files found during file adoptions(or RAW DOS orphans). The
default echo area specified for the particular area the file was
found in is the echoarea name used to hatch the file out. Also,
the downlinks for the echoarea is used for hatching. This can
also be disabled via the command line. Please Read the section
on "Using Base Runner" for more information.
- Scr Blanker
-----------
BREdit has a built in screen blanker which will dim your
screen after this specified number of minutes has elapsed with
no activity on either the keyboard or the mouse. After the
screen has blanked out, you may press any key or press the left
mouse button to light it back up again.
- Minimum Drive Space?
--------------------
This is the minimum drive space required before files can be
copied or moved to destination drives. This value should be
entered in kilobytes. (Bytes divided by 1024). If no setting is
provided, the default of 5000 (5 megs) is provided for you.
- Log Format
----------
Base Runner supports many logging styles. This is constantly
being added to but at the time of this printing, the following
types are supported...
- Front Door (or Intermail)
- QFront
- Remote Access
- PcBoard
- Base Runner (something different)
Selecting on the menu the type you wish to use will alter that
type to the style that is seen in that type of log format.
1.2.3
System Info - Network Addresses
-------------------------------
These are network addresses you may have within a Fido type
network.They can be up to a four dimensional address,but must
include at least 2 dimensions. I'll explain.
A Fido address is comprised of up to four possible numbers:
Zone:Net/Node.Point ...or...
1:229/428.2
The first number is the Zone, and usually refers to a major
geographic area such as North America or Europe. It can also
refer to another type of network other than Fido such as
SearchNet (Zone 114) or DharmaNet (Zone 96). The second number
is the network number within a particular Zone. The third number
is the node number within a particular net, and the fourth is a
point number.
The Zone number is optional if you're only dealing with one
network. The point number is optional unless you're a point
under an existing node. In any case, a net/node number MUST be
present. ie.
1:229/428
229/401
401 <- Invalid!
Remember these are YOUR addresses. Only one is required but
you may enter as many as you have up to 10. The first address in
the list is your main address. You will find reference to what
you enter here when (and if) you configure file echo areas.
1.2.4
System Info - Origin Lines
--------------------------
There are up to 50 origin lines you may have added to messages
that are generated by Base Runner. You may enter any text you
like. This text may include PCB's @-codes(as long as others will
tolerate it!) or whatever text you wish to insert. Afterwards,
when you are in echo areas, you may select from a list of these
origin lines, one for each area, and have Base Runner use that
particular one for that particular echo area. Not much more need
to say anything on this one.
1.2.5
System Info - Virus Scanners
----------------------------
Here you may enter up to 10 virus scanners to run on each
imported file. This may seem like overkill but it is for those
who are weak at heart and/or a little paranoid. Just leave any
program field blank to disable that particular virus scanner.
Leaving one empty will not disable one after it, they are all
checked for validity. Two fields apply here, the program
name(include the .EXE for speed) and the command line. These
should be self explanatory. As with most programs, a zero
errorlevel is assumed to be a successful return.
1.2.6
System Info - Compression Formats
---------------------------------
Base Runner supports an unlimited number of archiver types.
The first seven are already filled in by you and should never
need to be changed for any reason. They are also there to
provide you with a guide for future entries. It must be now
stated that there are NO other TIC/File systems that deal with
this properly at the time of publication of this document. The
reason for this is that no one program allows for all command
lines to be entered, does not allow for the possibility of a non
recursive archiver(such as older PKARC or PKPAK) and while some
archivers may indeed recurse(pull in sub directories) , they do
not necessarily put those sub directory paths into the newly
created archive. Base Runner covers ALL the bases(pun fully
intended) here.
Base Runner does not rely on your archive extension to provide
proof positive that this indeed is the archive type we are
looking for. Instead we use what we refer to as an archive
stamp, a series of identifying bytes at a given offset of the
file. For example, some are easy... RAR uses the word RAR! at
offset 0 but some others do not provide such an easy way to
identify themselves. Base Runner provides up to 10 byte values
as an array of bytes in order to identify an archive type.
Enough of the technical issues, lets get on with it. In order
to do that, lets first discuss one archiver itself. This means
that we are discussing what you would see if you were to press
enter(for editing) on any one of the archivers you presently see
in the window. Each item of this window is explained here...
Ext.
----
Only used as a way for us to know the difference between
types, this is the 3 character extension of the archive, for
example ZIP, ZOO, ARJ etc. This has no meaning nor is used in
any other way except to identify which archiver is which.
Stamp Offset
------------
The offset(how many bytes into the file from the beginning) of
the beginning of the archive stamp(see below).
Recursable
----------
If this archiver is capable of taking sub directories and
storing them into the archive along with their respective files.
Most archivers do nowadays, but some older ones don't. This is
especially important in the case where you are performing
archive conversion. If you insist on converting to a type which
is not recursable, understand that you are losing the integrity
of the archive by placing all the files into one main directory.
More about conversion later.
Extract1
--------
Recursable command line, if applicable, or empty if this
archiver is non recursable. This should include the switch on
the command line to include recursion, usually optional. There
are two macros available here, %F for filename and %D for the
directory. The %F will be replaced with the current filename
being worked on and the %D will be substituted for your work
directory.
Extract2
--------
Opposite of above, this is used to NOT extract paths but to
place all files in one directory. This is in case we are
converting to a non recursable archiver type, we want to make
sure to place all files into the main directory so that the
other archive type(the one we are converting to) will be able to
at least see all the files. This is not to even mention that we
feel that to convert to a non recursable type will fail to
maintain archive integrity. As above, the two macros, %F and %D
can be used here. See below for a complete list of available
macros.
AddFile
-------
Command line for adding files to an archive. One file or many
files may be inserted depending on the % parameter in the file
area editing so no "%" is required here, only the macros
supported for this section of editing. These macros are %F and
%A.
DelFile
-------
As above except this one deals with deleting file(s) from the
archive. These may include such files as known BBS ads. Some
processors allow the manipulation of distributed archives. We
feel this is a violation of how the archive was intended to be
distributed and will not support that aspect of operation,
however, we do allow you to manipulate the files coming onto
your system. Above only deals with echoed files. Available
macros here are %F for filename and %S for stripfile(or
delfile).
Comment
-------
Command line for inserting comments into archive headers.
Available macros are %F for filename and %C for comment file
or comment line.
Convert
-------
Here we must point out how the archive conversion works. As
you may already know, all files get extracted into your work
directory, possibly recreating sub directories where needed. As
well, all embedded archives are extracted into the embedded work
directory(just to keep it all organized for possible
conversion). With this, you must use a recursive call to include
all sub directories on this command line. If you have this set
to non recursable in the toggles above, then the original
archive type should have only extracted files using extract2
command line, so this archive type will still see all the files,
it won't keep the original directory structure. Starting to see
why we need two extract command lines? One to recurse subs and
the other not to.
Stamp
-----
As explained above, this is the archive identifying stamp that
is found in the file at a certain offset(see above). Placing a
zero in the last position tells us to stop comparing bytes, so
it can be considered an End of Line marker or delimiter. You may
place up to 10 bytes into this field. 3 digits ranging from
0-255 are allowed here, but no higher as it is impossible to
have a byte with a value higher than 255 in the file. Please
note that this is not hex as with other processors. This is a
digit format, much easier and faster in execution. So, for
example, using RAR would have the characters Rar!, which would
translate into 82(R) , 97(a), 114(r), 33(!). This may seem
confusing but it is very efficient. Besides, almost all
archivers provide these values for you in their documentation.
If you are confused about a stamp, please send it to us, we will
set it up as a default and give you back the modified dat file.
Summary of supported Archiver macros
------------------------------------
%A - AddFile(s).
%C - Comment file(s)
%D - Work Directory.
%F - Archive filename.
%S - Del file(s) (or Stripfile(s))
1.2.7
File Folders
------------
File Folders are a way of giving some common point of reference
between file areas with similar qualities. For example, you
might have public areas and private areas and want some way to
differentiate between the two.
In file area configuration, where you specify which file areas
Base Runner will maintain, each area is assigned to a folder you
specify here. If you define two folders, Public and Private,
each area you define in file area configuration will belong to
one of these two folders, whichever you choose.
Their most efficient use is in echo area configuration, where
folders have a strong bearing on security. Any other BBS
Base Runner might feed will have access to selected file folders.
There is more detail on this aspect later on.
For the most basic configuration, one folder is required and no
more. You can ignore the feature if you have no use for it. You
may find the need for them as you go through file area
configuration.
One thing to remember, file folders are ECHO oriented and used
only by that end of the system. We found it necessary to implement
a security type of system for the requesting end of things. For
this reason, please don't run off configuring these folders for
file requesting. For those you will assign a security level to
each node. More on security levels later.
1.2.8
BrConfig Databases
------------------
Before going any further, something should be said about how
BrConfig handles its own information. For Node Info, File Areas
and Echo Areas, BrConfig uses an indexed database to store each
record. Manipulating this database has been made fairly easy.
When you first enter one of these sections you get a horizontal
list of any existing records. You can cursor/page up/down to
move through the records.
All operating commands are done using ALT keys. The following
is a list of available commands, but note that there may be extra
options specific to what the database covers (file or echo areas
etc.).
ALT-A - Add a new record
ALT-D - Delete a record
ALT-F - Find/Searching Functions.
ALT-G - Global Menus(except Nodes).
ALT-H - Help. F1 will do the same job.
ALT-P - Pack deleted records
ALT-X - Immediately exits configuration program, saves files.
Note that deleting a record only marks it for deletion. ALT-D
will toggle deletion status on and off. ALT-P actually removes
the records from the database.
- Common Cursor Commands that are Used by all Databases.
UPARROW - Moves current selection up one item.
DOWNARROW - Moves current selection down one item.
PAGE DOWN - Moves current selection down 15 items or end
of file.
PAGE UP - Moves current selection up 15 items or to top
of file.
CTL PAGE UP - Same as two pages or 30 items up.
CTL PAGE DOWN - Same as two pages or 30 items down.
HOME - Two way function. If not currently at top of
screen, moves current selection to top of
screen, otherwise to top of file.
END - Two way function. If not currently at bottom
of screen, move current selection to bottom of
screen, otherwise to bottom of file.
ESCAPE - Always takes you out of (backs up) the current
database or out of whatever operation within
that datbase you were doing. This is not
limited to the databases but is consistently
the way to back out of ANY operation at any
time.
1.2.9
Node Information
----------------
Node information is another database which keeps track of all
nodes you communicate with. If you are sending or receiving
files to/from other systems they MUST be declared here or
Base Runner will not recognize them.If you don't plan to run file
echoes or file requesting this section can be ignored. The
information is minimal but required. However, before we continue
I should explain a couple of terms used in this section and how
they apply.
Uplink Lists/File Lists
-----------------------
An uplink is the system you get your files from. You could get
files from more than one place, but we'll focus on a basic Fido
setup to make things easier. If you are hooked into file echoes
via the Fido backbone, typically you'll get your files from a
central hub or host. This host is considered your uplink. Any
systems you pass these files on to are your downlinks. To your
downlinks, you are their uplink. An uplink list is a text file
containing a list of file echo areas available from your uplink.
Base Runner requires a text file, one file echo area per line.
Each line should have a valid file echo area name such as PDNCEE
followed by a space and optional description for the area. You
can have up to 15 uplink lists for each node you connect with.
Auto Area Creation
------------------
Normally if you request new file echo from your uplink you have
to manually create a file echo definition (explained shortly), a
directory to store the files and so on. Base Runner gives you the
option to automatically create a file echo area and its
directory. More details on this to follow.
Auto Unlink
-----------
Say one of your downlink requests an area called PDNCEE. You
set the area up and get the feed going from your uplink. Then
your downlink doesn't want it and disconnects it. You're left
with an area you don't want. Auto unlink will monitor this area
to see if there are any downlinks declared for it. If there are
none, it will generate an area manager request to your uplink
disconnecting the area for you. This is mentioned here only
it is node related, but it the work is done via BRUTIL.Please see
section under BRUTIL for more details on Auto Unlinking.
Area Request Forwarding
-----------------------
Any of your downlinks can request echo areas available on your
system. If you don't have an area they might request, normally
they're sent a netmail message stating the area is unknown.
However, this could be an area available from your uplink. If
you enable request forwarding and a downlink requests an echo
area not in your configuration, Base Runner will search the uplink
list you've declared for this node looking for that area. If
it's found, an area manager request is generated for your uplink
requesting the area be connected.
With these few concepts in mind it should be easier to
understand the options below which refer to each node you
communicate with.
- Address
-------
This is the Fido address of a given node you communicate with.
It is a 4D address as specified earlier. If you enter a partial
address here such as "400", Base Runner will rebuild your entry
based on your primary node address. For example, if you entered
"400" here, when you move to the next field it will change
automatically to 1:229/400.
- Route To
--------
If you would like to temporarily reroute files to an alternate
node on this nodes account, you may do this by specifying a node
address in this field. The Address field is ignored while there
is a valid entry here.
- Sysop
-----
This is the name of the sysop of your system.
- Area Manager Password
---------------------
This is the password used by the specified system to access the
File Manager. More on the File Manager later.
- Folders
-------
This is a pick list of the folders you defined earlier. You
hit the spacebar for every File Folder that this node has access
to. For example, say you defined two groups, one Pay Echoes and
one Free Echoes. Under File Echo Configuration you specify which
folder each file echo belongs to. Then here, you specify which
of those folders this node has access to. So if this system is
behind on payment of pay areas, you can just untag the Pay Echoes
folder here and he can no longer access these areas using the
File Manager.
- Attach Flag
-----------
This is the attribute of netmail messages sent to this system.
There are six options here:
None - Normal routing looks after sending.
Crash - Messages are sent NOW.
Hold - Messages are held for pickup. Not sent.
Direct - Messages are set up as direct with no routing.
Crash Direct - A combination of Crash and Direct.
Hold Direct - A combination of Hold and Direct.
- Auto Create?
------------
This option enables the auto area creation feature as explained
above. This needs some explaining. Since Base Runner has a two
tiered system of echo areas and file areas, there has to be some
provisions made to accomodate the differing scenarios desired.
The first menu item here is Off, which is simply to turn off
auto add altogether. Please remember that you are then required
to add the area yourself or disconnect it from your uplink. The
second option is Clone Farea, which means that a file area is
created for each echo area created with its own unique directory
, filebase and descfile. This will ensure that each echo area is
attached to only one file area,the opposite being a very powerful
feature of Base Runner which brings us to the third item. Use
Initial tells Base Runner that you wish a new echo area to be
created but to have this area point to an initial file area as
specified in the initial field of the echo clone record. In this
case the initial field becomes the name of the file area that all
files entering this echo will go to. You might want to play with
this to achieve the desired result as there is much flexibility.
The last item therefore allows all new echo areas from one node
to point to only one file area, allowing you to later go and
reconfigure to a new file area or to push all files entering the
system from that node to see only one file area. This also allows
categorization of nodes so that one area may be devoted to one
node.
- Clone Farea?
------------
If auto creation is enabled, any time an area is auto created
it needs a guide for the various options in your file area
configuration. If you like you can create a generic file area
used strictly for cloning. So if the area PDNCEE is
automatically created, the new file area will take on the options
the file area you declare here currently has with two exceptions.
The first is of course the area name. The file area name will be
the same as the file echo area name. The other is the path to
where the files are stored. Say the area you are using for
cloning is C:\FILES\IBM. Base Runner will recurse this path one
directory and replace it with the first 8 characters of the echo
name. So if the area PDNCEE was being created, the path in the
new cloned area would be C:\FILES\PDNCEE. Note that if you
haven't configured file areas or echo areas yet there will be no
areas to choose from. Do that first and then set up area
cloning.
- Clone Fecho?
------------
This is similar to the above, but refers to the file echo
record in Echo Area configuration. As with the above example,
the echo area record you specify here will be used to create a
new record. The initial area to place files in this echo will be
the same as the area being cloned. The area that owns files
coming through this echo will be PDNCEE (if that is the area
being created). All other options follow the area being cloned.
- Announcement
------------
Announce to which area is the main point of this field. Enter
the echomail conference you would like this echo area to
announce to. A packet is generated(or appended to if one from
this node already exists) and this message is added as an
announcement. If that area is set up as an echo area and your
processor can scan outgoing mail, you will then notice the
message going out to other nodes as well as going into your
message bases. Remember that this is only for user requests and
not the announcements used for echos.
- Request System?
---------------
This is for PCB sysops only. You may connect to this system
for offering your users access to their files area. Of course
only the areas they are configured for and the ones you have
enough security for are open to you. Answering "Y" to this
question will automatically signal BRFREQ to include this
systems name as one of the available systems from which your
users can request from. Please remember that you must have a
directory and their files areas data files in order to operate
properly in the door or your users may get confused, so
answering "Y" to this requires that you completely set up this
node for user file requesting.
- System Name
-----------
The name as it will appear to the users who are using BRFREQ.
When they go to log onto (or enter) another BBS, they use the
"S" command. This name is what is used as the system name for
this system.
- Request Directory
-----------------
The directory(no backslash) of this nodes files areas
databases and control file(AREAS.CTL). This directory is
automatically maintained by Base Runner and used to store all of
this nodes areas and requesting info in.
- Security Level
--------------
Security level for this node. This level is compared to the
level specified for each file area. If this node has enough
security, they have access to that area, otherwise, it is
invisible to them or their users. Requests to this area are
ignored as well.
- Request Message Base
--------------------
This is the echo area name of the message area you wish the
announcements to go to for incomming files from this node. You
will have to(if you want to keep it local) set up a dummy echo
area in your echo processor to import these messages with no
downlinks so that it remains local or you may announce each
users incomming requests to any echo area. Packets are generated
for these messages similar to regular Announcements.
- Request Message Text
--------------------
As with Announcements, this is the templated text file that is
used for the generated messages. It is replaced using any macros
found in the original and the new packet(or an existing one) is
appended with the new message. Your regular mail processor can
then process the incomming mail as it normally would.
- Day Bytes(K)
------------
This is the number of kilobytes this node has taken today. If
the bytes cap is set to anything other than zero then that value
is compared to this one to see if this one has exceeded the set
limit for the day, otherwise it is incremented here and also
incremented in the totals field as well. You can reset this
without affecting the totals field. This applies to user
requesting only and does not affect the regular nodes echo
statistics.
- Day Files
---------
As above except that this is for file instead of bytes. The
same rules apply to the files cap if it is a value other than
zero and resetting this does not affect the total files field.
This setting pertains to user requesting only, not echo traffic.
- Total Bytes(K)
--------------
The total kilobytes this node has taken to date or since the
last time you reset this value. As above, this field applies to
the user requesting operations and not the regular echo traffic.
- Total Files
-----------
The total number of user requested files this node has taken
to date. This may be reset at any time.
- Bytes Cap(K)
------------
Number of kilobytes this node can take each day for user
requests. If this number is set at zero, it is assumed as an
unlimited value and will not be checked.
- Files Cap
---------
As above, but for files instead of bytes. If this value is set
at zero, unlimited is assumed.
- List Delay
----------
The number of minimum days before and update will be sent to
this node. This is handy if you are long distance or do not want
too many copies flying back and forth. These are the lists that
you maintain for this nodes file areas for your user requesting
system. If this value is zero, lists will be updated as they are
needed(default).
- Kilobytes In (back to regular input screen)
-------------------------------------------
This is the total kilobytes that this node has sent you. It
reflects the total amount since the last time it was reset.
Please note that this field is for echo activity and not user
requesting activity.
- Files In
--------
As above except for files instead of kilobytes, it reflects
the total this node has sent us.
- Kilobytes Out
-------------
The total kilobytes that we have sent this node to date or
since the last time it was reset.
- Files Out
---------
The number of files we have sent this node to date or since
the last time it was reset.
- KB Cap
------
Kilobyte cap for this node. When this total is reached, all
echo activity for this node is stopped and any files going out
to this node will be stopped at that point.
- File Cap
--------
As above, except that the cap is for the total files this node
can take instead of kilobytes.
- Area Manager Name
-----------------
Your uplink may be running a file echo processor other than
Base Runner and Base Runner has no way of knowing who to address
requests to. eg. FILEMGR, TICK, ALLFIX, etc. This field
specifies the name your uplink will recognize as a file echo area
manager request.
- Area Manager Netmail Status
---------------------------
This is the attribute of Area Manager netmail messages sent to
this system. There are six options:
None - Normal routing looks after sending.
Crash - Messages are sent NOW.
Hold - Messages are held for pickup. Not sent.
Direct - Messages are set up as direct with no routing.
Crash Direct - A combination of Crash and Direct.
Hold Direct - A combination of Hold and Direct.
- Days to Keep?
-------------
Most TIC processors force you to register for this feature but
it is included with the Base Runner package. This setting tells
Base Runner how many days you wish to keep attached TICs and
files around before deleting them. This may be a value between 0
and 65535. A setting of 0 denotes unlimited days.
- Notify?
-------
This tells Base Runner whether or not you wish to send this
node notify lists when invoking BRUtil to generate the necessary
netmail attaches. Any node may get a list but it is only going
to reflect the areas they are hooked up for as well as some
other system related information such as Traffic statistics and
passwords etc. BRUtil may be set up using the command line
version in an event periodically to update your downlinks(for
example) or any other nodes set up for notify with this notify
list.
- Advanced Tic?
-------------
There are currently two tic format modes available in Fido
today. You can use "Normal" or "Advanced" tic modes using Base
Runner. If you select "Y" here, the advanced tic will be created
or if you press "N", the normal tic type will be use. The more
advanced tic type includes such fields as LDesc, To and a couple
of others where the normal style does not.
- Maximum Downlink Archive Size
-----------------------------
You can limit(or the downlink can limit) the size of the out
going archives to a particular node. This is the maximum size in
kilobytes of the archives. If an archive is found to have reached
the limit, a new archive is created and processing continues.
This value may be any value between 0-65535Kb.
- Compression Format
------------------
Further to the Ticmode selection, the "packing" stated refers
to the compression of the tics and/or files into archives. Base
Runner can support an unlimited number of archivers so with this
, all these types are available to you to use as a default for
this node. This will only be active if you are sending TICs or
files to this node, meaning this node is a downlink from you.
- TicMode
-------
There are a few selections available to you on this menu.First,
this is a menu where you can select the ticmode for this node.
Ticmode in this instance refer to the way that this node receives
their files. The following are available and are explained a bit
further...
File - Just sends a file, no tic nor compression used.
Pak Tics - Pack TIC files but attach files regularily.
Tic/File - TIC and file is attached normally. (default)
Pak Files - Packs files without TIC files attached.
PakBoth - Packs both TICS and files into one archive.
So you see, there is a lot of power here. You can send files or
pack files or pack tics and send files or pack files and tics
etc...
1.2.10
BBS Areas(File Areas)
---------------------
Think of the file areas on your BBS. You have a DIR File that
holds the information about the files that reside in a directory
on disk.A file area under Base Runner is the same thing except for
one difference. It maintains its own file database with the same
information as the DIR file plus a bit more. It is also indexed
for faster processing. The actual DIR File is a reflection of
the Base Runner filebase and is regenerated any time the filebase
or the associated files change.
Everybody has a new upload area. Each file area you define
under Base Runner requires a unique one word name like NEW_UPLOADS.
Note that although file echoes have a similar naming procedure,
this is NOT the same thing. It denotes file ownership, as
described earlier.
This section of configuration allows you to define as many file
areas as you wish.It uses an indexed database to hold the areas
you define.So what do you define? Start with NEW_UPLOADS. Enter
the areas under Base Runner just as you did with PCBoard.
Something else to note is that a file area under Base Runner has
a certain behavior.Files entering a given area are processed in
some way and in this section are MANY options for how the files
in each area are treated. NEW_UPLOADS may be configured to
convert compressed files to ZIP and scan for viruses whereas the
area GAMES-A_L may not have any processing done on its files at
all.
Base Runner is very flexible in all aspects of file maintenance
and it will do just what you tell it so be careful. Each option
will be covered in detail, and this one section will complete
basic operation.
- Area Name
---------
This is a unique name given to a file area. It MUST be one
word. You can use dashes and underscores within the name also.
The only thing to remember here is that the name is unique. It
can be the same name as a file echo, but you cannot have two file
areas with the same name. Pick any name, it doesn't matter.
Examples are NEW_UPLOADS, NEWUP90, IBM_GAMES_A-L, etc.
- Description
-----------
This is a short description of the area such as "New Uploads"
or "IBM Games A-L". It will appear in DIR headers/footers and
various reports. It can be anything you like.
- File Directory
--------------
This is the path to where the files for this file area are
stored. BrConfig will strip a trailing backslash if you add one
and verify that the directory exists. If not, you will be
prompted to create it.
- BBS File Base
-------------
This is the path and name of the PCBoard DIR file that holds
the information for the files in this area for the BBS.Base Runner
will regenerate this file as it processes based on the
information in the Base Runner filebase. Please note that for
FILES.BBS type systems, the actual name of FILES.BBS need not be
added to this name, rather just the path(excluding trailing
backslash) to the FILES.BBS file. It is usually placed in the
same directory as the files for that attached area. This allows
for the lack of space in the editing field for FILES.BBS
systems. With PCB systems, Base Runners editing field length
matches that of PcBoards so it is not a problem, but with other
systems, there are sometimes longer fields offered.
- File Base
---------
This is the actual filename of the Base Runner file database for
this area.Base Runner filebases consist of 3 files. Say you enter
NEWUP in this field. When Base Runner processes it will create:
NEWUP.HDR - Holds information on all files in this area
NEWUP.IDX - An index to the above
NEWUP.TXT - Holds all the description text for that area
You can call the actual filebase anything, but it must conform
to DOS file naming conventions.
- Folder
------
This assigns this area to a folder you have defined previously
in configuration. Say you defined two folders, "Private" and
"Public". If the current area is private, assign the appropriate
folder to it.
- Hatch To?
---------
An area that new adoptions will hatch new files to. This is an
echo area that is configured so that if adoptions for this area
is on then this will be the echoarea that this file will end up
being hatched to. This echo areas nodes including uplinks will
receive both a netmail attach message and an attached TIC file.
Each nodes message status bits(CRASH, HOLD, NONE) are set up in
each of their messages so that your mailer can know how you want
their mail to be handled. This is handy for putting cerain nodes
on hold in case they are polling you instead of the other way
around.
- BBS Header
- BBS Footer
----------
In your PCBoard DIR file, Base Runner can place a header at the
top of the listing and a footer at the bottom. If you leave
these fields blank headers and footers are ignored. If you place
a path and filename here, Base Runner will use the specified files
as the header and/or footer. Headers and footers are fully
configurable. One example of each is included in the
distribution package. See the later section on Custom Headers
and Footers on how to create your own.
- Add File(s)
-----------
This allows extra files to be added to compressed files that
enter this area. These can be BBS ads and so on. You can
specify a single filename here, or if the filename is prefixed
with a %, it is assumed you are specifying a text file with a
list of files to add. For example:
C:\DBASE\BBSAD.TXT - Adds this file to files entering this area.
%C:\DBASE\BBSAD.LST - Adds files listed in this text file.
The file can be any name, and must contain one filename per
line, any number of lines.
- Del File
--------
This functions basically the same as the above option except
the file(s) will be removed from compressed files.
- Zip Comment
-----------
Some compression formats such as Zip can have a header placed
within the file that is displayed when the file is decompressed.
You can either enter a single line of text here, or specify a
file to use as the comment by prefixing it with a % like above.
The difference between the above and this is that the above takes
a file with a list of filenames and adds them to the compressed
file. This option uses the entire content of the text file as a
comment.
That text can be up to 80 characters wide, but should remain
under 25 lines long (a full screen). Note that special codes
such as ANSI or PCBoard @ codes should not be used. ANSI codes
are stripped by some compression programs.
- Max Files
---------
Specifying a number here, limits the number of files in this
area to that number. So if you enter 1000 here, and during a
process Base Runner moves files 1001 & 1002 into the area,the two
oldest files are deleted. Specifying 0 here disables this
function and lets the area take files as normal.
- Delete Age
----------
Base Runner will delete files by age in a file area.If you
specify 90 here, files older than 90 days are deleted.
Specifying 0 here disables this function. Please do not confuse
this feature with the "Deletions" switch below. With that function
you are deleting any records that don't have an existing DOS file
in its directory.
- Traffic
-------
- Convert?
--------
Enabling this option will convert all recognized incoming
compressed files to this area to any other recognized format.
The destination format is specified below.
- Virus Scan?
-----------
This option will cause Base Runner to scan any files into this
area for viruses using the program defined in System Info. Any
files that fail are either deleted or moved to the BAD area,
whichever you specified in System Info.
- Dupe Check?
-----------
Check this area for duplicates? If yes, duplicate files and
filebase entries are either deleted or moved to the BAD area.
- Deletions?
----------
One of Base Runner's features is the ability to compare the
directory and the associated filebase, and remove those entries
that do not have a matching file. This and the next option
ensure that each file area is up to date.
- Adoptions?
----------
This process is similar to the one above except that it adopts
files that exist on disk but do not have a filebase entry. Using
both of these options ensures that the file area is always up to
date, reflecting all files that exist.
- Uploads?
--------
Base Runner will search through your BBS file areas and import
any new uploads it finds. During this time, there are some
limited processes performed on the file but Base Runner does not
pretend to be an upload processor so the operations are kept to
only with Base Runners filebase needs as well as some pretty
intense 3 level duplicate checking. The reason Base Runner does
not get too involved in this aspect is that not enough control
is afforded to Base Runner unless we were online when the user
was uploading the file. This way such things as demeriting the
users credits could be performed. CompuData currently has one of
the finest upload processors on the marked called SpotChek in
release. We invite you to have a look at it to see what we mean
by TOTAL control during the upload process. Besides, most BBS's
have ample upload processing available to them at runtime.
Please note that because the file is already in the DIR(or
FILES.BBS) file, this file is not regenerated again unless you
use the utility program to automatically regenerated with an
implicit call to do so. We feel there is no reason to regenerate
them during this operation.
- Requestable?
------------
This option determines whether this file area is eligible for
file requests from this area. If "N", this area won't even show
on file request updates.
- System Wide Duplicate Checking?
-------------------------------
Base Runner has the option of checking for duplicates in one
of 2 fashions and has a 3 tiered system for detecting duplicate
files. Firstly, if this toggle is set to "Y", then Base Runner
will check this file against all files in all areas, otherwise
it will only check against files that have come into this area.
The 3 tiers of duplicate checking are done as follows.
- Crc calculation of filename and extension.
- Crc calculation of the whole file, byte by byte(longest).
- Crc calculation of file areaname.
- Orig. Dates?
------------
Keep original file dates?If Yes,Base Runner will NOT change the
dates of the files that enter the area. If No, Base Runner will
change the date of all incoming files to today's date.
- High Ascii?
-----------
If you specify No here, high ascii characters will be stripped
and replaced with lower ascii characters. High ascii characters
are those like smooth lines and boxes. Some file echo networks
don't allow them, but most do anyway.
- Sort by?
--------
Sort the files in this area by filename, date or none at all,
whichever you prefer.
- Sort Ord?
---------
This is the sort order for the above, ascending or descending.
Note that this option has no effect if you specify no sorting
above.
- Convert to?
-----------
This is the compression format to convert compressed files to,
if you enabled conversion earlier on.
- FILE_ID Option
--------------
There are three options here dealing with how Base Runner treats
FILE_ID.DIZ files for incoming files. They are:
Needed - Only if the FILE_ID doesn't exist, is one added.
The description from the TIC file is used in this
case.
Always - FILE_ID's are always added, regardless if there is
already on there.
Never - Base Runner ignores anything to do with FILE_ID's. No
description processing is done at all in this case, in
other words, this is not to say that there will be no
description, only that no file id file will be
inserted whatsoever.
Please don't confuse the echo area tic options, they are only
whether or not to use the TIC description or take it from the
file id. In that case, the echo areas options take place
first. For this reason, the usual option here is "needed".
Base Runner works optimally using the needed specifier.
- Security
--------
This is the security that a requesting node needs in order to
see this file area in one of their lists. If their level is
lower than this value, they can't request from this area and any
attempt is a security violation and is refused and logged. This
may be a value of up to 65534 so you have great amounts of room
to expand on your requesting system.
1.2.11
Importing from PCB's Bases
--------------------------
This area was selected for explanation of the Alt I, PCB import
command. If you press Alt-I, you will see all the areas PCB has in
it that your Base Runner system hasn't. In other words, the
DIR.LST files are read as per your PCB configurations and a list
is built which is displayed to you. Here you may select with your
space bar any areas you wish to adopt into your file areas. Please
note that the area names are built from the actual DIR.LST
descriptions, so some ambiguity is bound to come from the
algorythm although the greatest effort has been made to always
come up with unique and original filebase names etc.
There are a few commands available to you at this point. You may
press Alt A to add all the areas in one keystroke. Spacebar for
individual items, Page Up to take you up 15 entries in the list,
control page up for 30 entries up, control page down for going
down 30 entries, control page up for going up 30 entries, home
works in two steps, the first will take you to the top of the
page, the second , or first if you are already at the top of the
page, takes you to the top of the file. By the same token, the end
key works just the opposite, giving you total movement flexibility
and selection control. When you are finished selecting the areas,
Base Runner builds areas entries the best it can based on the info
it collects up from your PCB file system, but it is recommended
that you edit these areas to gain the most advantageous properties
as this is a very complex and powerful file system.
1.2.12
File Area Links
---------------
When in horizontal list mode, you have the usual add and delete
commands to manage each record, but for file area configuration
there is one more option. Highlight a record and press ALT-L.
(or press the spacebar)You will be presented with the following:
- Days Old
--------
This specifies how many days old a file must be before it is
automatically moved from this area.
- Echo to Area or Hatch to
------------------------
This allows you specify which echo area this area sends new
file adoptions to when it finds new files in the directory.
- Move to
-------
This allows you to specify where files in this area should be
automatically moved to after the above Days Old value has
expired.
Days old and Move To deal strictly with automatic file
movement. They are fairly straight forward, but there are
options as to where files can go. You are presented with a pick
list of your file areas, but there are two options at the top of
the list that are a bit different:
- Nowhere
-------
This is a magic word recognized by Base Runner that tells it not
to do ANY movement on this area. No automatic file movement is
performed.
- Home
----
This will move files "Home" or, to the file area that connects
to this file. A "chain" of areas can be created so that the file
can flow through your system. By specifying "Home", you tell Base
Runner to move the file to the chained directory rather than move
it to nowhere.
With these two options, you now know that a file is considered
"dead" once its owned areaname matches the current area name. By
simply typing in either the name "NoWhere" or "Home" Base Runner
will recognize it(case is not important) and act on it properly.
Please note that these areas need not exist, they are but phantom
area names that trigger Base Runner. All operations Base Runner
will do recognize these "keywords" or areanames.
This entire section can get a bit confusing, but it is designed
with the most flexibility as possible. The best thing at this
point is to explain some possible area link setups so you get the
hang of it. Imagine a system with the following file areas:
NEWUP30 - New Uploads 0-30 days old
NEWUP60 - New Uploads 31-60 days old
NEWUP90 - New Uploads 61-90 days old
GAMES - Games...
UTILS - Utilities
GIFS - GIF Pictures
Now look at the same list, but with a possible area link
configuration:
NEWUP30 - All new files go here first, move to NEWUP60
NEWUP60 - Move to NEWUP90
NEWUP90 - Move to "Home"
GAMES - Move to "Nowhere"
UTILS - Move to "Nowhere"
GIFS - Move to "Nowhere"
Note how files will move through the areas (30 days at a time)
and eventually where they belong. The "where to place uploads"
option as described above is set to NEWUP30 for all areas. This
ensures all new files are posted in NEWUP30.
Another twist you can add is an area called UNTESTED. I would
define this as an internal private area not available through the
BBS. All new files would go here first, and the area is
configured to do all the work; zip conversion, virus scanning,
add files, etc. The area is also configured to move files to
NEWUP30 after *1* day. What happens is when Base Runner runs
after midnight, all new files for the day are processed and posted
in NEWUP30. The rest of the area links take the file from there.
PCBoard users may use different conferences but Base Runner
doesn't care about any of that. If a file area belongs to a
certain conference, it's up to you to specify which upload or
file area new files are uploaded to and placed in. Base Runner
looks after up to 65,000 file areas and doesn't care about what a
conference is.
That should get you started with file area links. You can have
files moved to any existing file base as you please based on the
age of the file. The above is only one possible setup. You can
define as many links around the system as you like.
1.2.13
Custom Headers/Footers
----------------------
As mentioned in file area configuration, Base Runner can add
headers and footers to your PCBoard DIR files. There is no
default for them, they are completely customizable. Included in
the Base Runner package are the files HEADER.PCB, FOOTER.PCB,
HEADER.ANS and FOOTER.ANS. The .PCB files are for use with
PCBoard and the .ANS files are for use with RA. They are
examples of how you can design your own headers and footers.
Basically, headers and footers are just text graphic files much
like the screens you design around your BBS. You can use any of
the variety of editors out there, Thedraw, PCBEdit, etc. They
can contain any kind of text you like. Just design them like you
would any other ASCII or ANSI/PCB screen. In addition are
special keywords you can place within the text that will be
translated into various parts of your system information. Below
is a list of these symbols and what they display:
SYSNAME - System name
SYSOP - Sysop name
LOCATION - Location
PHONE - Phone #
FILES - Total files in a given file area
BYTES - Total of all files in bytes
KBYTES - Total of all files in kilobytes
AREADESC - Area description
UPDATE - Date the header (and listing) was created/updated
FIRST - Earliest file date of all files
LAST - Last file date of all files
AREANAME - Area name (as defined in file area config)
Anywhere in the header or footer text you place these keywords
and their corresponding information will replace the symbol when
Base Runner regenerates the DIR file. You may think that it's
possible these keywords may conflict with ordinary text but
there's one thing missing.
These keywords are to be bracketed by one of 3 other characters
that denote their justification. The following are the available
justification characters:
% - Left Justify
Left justification starts where the first % character lies like
so:
%SYSOP%
Steve Tupy
@ - Right Justify
Right justify is a bit different. The LAST character of the
inserted string is placed on the LAST @ character. You can use
this feature to ensure inserted text does not extend past the
right side of the screen. ex:
@SYSOP@
Steve Tupy
^ - Center Text
Centered text is based on 80 columns wide and text will always
follow this rule. In other words, you cannot use this character
to center text between columns 1 and 40.
^SYSOP^
Steve Tupy
Suppose you wanted your header to start with the area
description centered on the first line. Your header text would
contain the following:
---------------------------------------------------------------
^AREADESC^
Total: %KBYTES%k Files: %FILES% First: %FIRST% Last: %LAST%
---------------------------------------------------------------
Keep in mind that color codes for PCBoard or ANSI can be placed
anywhere in the text. The result for a given area might look
like so:
---------------------------------------------------------------
New Uploads
Total: 32046k Files: 1035 First: 01-01-80 Last: 01/01/95
---------------------------------------------------------------
Keep in mind that you will have to leave enough room for the
widest possibility. %SYSNAME% is somewhat shorter than
"CompuData Systems BBS". Also remember that you can spruce
up these files with ANSI color or PCBoard @ codes, as well as
smooth lines and boxes. The final look is completely up to you.
You might have to play with it to get used to the placement of
keywords and color codes but you'll get the hang of it.
You don't have to have both headers and footers and you don't
have to have any at all. If you leave either or both options
blank in file area configuration headers/footers will not be
generated for that area.
1.2.14
File Area Global Menu
---------------------
If you press Alt-G in the file area manager, you will notice a
new menu popping up in front of you. Here you may do certain
things globally on more than one record at a time. This allows
for global editing which can save you alot of time, especially if
you run a large hub system. Here we will go over the menu items,
what they do and ways to optimize your use of folders. Folders
are the system used to identify which records you want worked on.
When you create areas in the area manager, you enter a folder for
that area. You should arrange these areas into folders in such a
way that they are related in some way. Some examples of this
would be Fido, PCB, ADS etc. Then in one quick stroke, you can
change or add field parameters which belong to the folder you
selected.
- Hatch To?
---------
Here you can change(or add if that area is currently blank) the
destination echo area this areas adoptions will be hatched to. If
the area being configured is set up for auto adopt(or hatching)
then this will be the areaname of the area to hatch to. FECHO.DAT
will be scanned for this areaname and when found, its defaults
will be used by Base Runner for such things as downlinks, uplinks
etc. Everyone in this list will recieve a copy of this file when
this hatching process is taking place. More on that in the
specified topic areas. You will first be shown a dialog allowing
you to browse and find the area you wish to hatch to. After
pressing enter you will be shown another dialog allowing you to
select the folder to scan for. Then all areas with this folder
selected will be modified. The number of changes will be reported
to you and you will then have to press any key to return back to
the global menu. You are then ready to do something else globally
or return again(by pressing ESC) to the viewing window.
- Header
------
This applies to the field in file areas that says "Header".
This is (more in file area configuration) the file that will be
placed at the top of the DIR file (Or Desc) for that particular
area. As above, you will have to select a folder after you enter
the path and name of the new file.
- Footer
------
As above except that this relates to the footer or bottom of the
DIR file.
- Add Files
---------
The path and filename to either a single file to add to the
archive or a group of files to add. See file area editing for
more info on this. As above, you will be required to select a
folder and will be reported on how many changes were made.
- Delete Files
------------
As above except that this deals with files to delete from the
archives.
- Comments
--------
The comment file(or line) that will be applied as the new
comment for files entering that area, this allows you to change
the comment file for areas in this folder(as above).
- Delete Age
----------
This is the same as the Delete Age field in file area editing
- Security
--------
Globally alter security levels for file areas as well.
- Max Files
---------
Sets up maximum files permitted in file areas.
- Toggles
-------
These are broken down as follows...
Convert,Virus Check,Dupe Check,Keep Dates,High Ascii Filter,
Requestable,CdRom Area,Deletions,Orphans,Wide Dupe and Active.
These are all self explanatory and are explained in detail
under the file area configuration section.
1.2.15
TIC Areas(Echo Area Configuration)
----------------------------------
Inbound files with accompanying TIC files are processed by
Base Runner based on what's in here. Each Echo Area you define
specifies how the files coming into the system are handled and
where they're placed.
- Echo Area Name(Tag Name)
------------------------
Note that this has NOTHING to do with File AREA names. This is
the area name for a given file echo. These names are assigned by
the originator of the echo which could be across the globe. Your
uplink for file echoes should supply you with a list of area
names he carries, and this is where that name goes.
- Comment
-------
This is just a quick description of this area such as "FidoNet
Nodelists" etc. It will appear in many different reports as well
as through the File Manager.
- File Folder
-----------
Here you select which folder this area belongs to. This is for
use with security as mentioned earlier.
- Message
-------
This is the path/name of a text file that will be used for
notification of new files entering this area. This may also be
called announcements. There are a number of macros supported for
the text in this file. They may be placed anywhere in the text of
this file and are listed as follows...
- %A% Echo(or TIC) areaname.
- %C% Inserts the description of this file, left justified.
- %D% Filedate in form MM/DD/YY.
- %E% Todays date in form MM/DD/YY.
- %F% Inserts the filename.
- %L% Systems City as configured in BRConfig.
- %N% Your systems name as configured using BRConfig.
- %O% Originating Node(Node address of system who sent us file).
- %S% Filesize of file.
- %T% Todays time in format HH/MM/SS.
- %Z?% Special macros which MUST be 2 wide. The "Z" denotes that
this is a format specifier. A format specifier will act
on its command. The "Z" command tells Base Runner to use
a different pad width. Each number here specifies a number
of 4 char tabs to insert before description text, so to use
%Z6% would tell Base Runner that when it encounters a %C%
, it should now use this value as its its leadoff value,
which would pad any descriptions after this by 24 spaces.
(It is wise not to pad over too far or you will see
wordwrapping in your announcement text). This allows you
to format the text any way you prefer for your announcement
message text (or template, if you will).
Only capitol letters enclosed by the "%" symbols will be
formatted into the text, all others will be assumed to be literal
text and will be ignored.
- Announcement Echo
-----------------
This is the echo area tag you wish to use as the area that the
message will go into. This is an area that your echomail process-
or will use to place the message into its appropriate base. PCB
as well as most other BBS packages support echomail tossing.
Using this type of system ensures that Base Runner will work
with whatever BBS package you decide to use. If you intend to
announce to an area which is not to be used as an echo area but
only as a local area, you must still set up this area as an echo
area. It will not affect the function of the area if you do not
downlink it to anyone else.
- Uploaded By:
------------
This is the default uploaded by string for this area. You can
put any text here you like. Placing %A or an %S on that line
anywhere creates substitutes for the echo area name and system.
For example:
Uploaded by %S to %A File Echo
Would show in the DIR file as:
Uploaded by 1:229/428 to NODEDIFF File Echo
- AKA's
-----
Here you select the AKA or node address that you are known by
for this echo. You select the number from the list of addresses
in System Info.
- Initial Area
------------
Now things get a bit trickier. This and the next field
determine where inbound files for this echo go now and later.
Say you define an echo area called NODELIST. When files enter
this echo, which FILE AREA (you defined earlier) do they go to?
Perhaps NEW_UPLOADS or a separate area called NETWORK_FILES.
You'll be presented with a list of the file areas you defined
earlier and asked to pick one.
- Owner
-----
This is the area that OWNS the files coming into this echo.
For example, say BESTPPE.ZIP comes into the echo PCB-PPE. You
have file areas defined as NEW_UPLOADS and PCB-PPE (note that
file areas and echo areas can have the same name). BESTPPE.ZIP
can be initially placed in NEW_UPLOADS but be OWNED by PCB-PPE.
Now when the file gets to NEW_UPLOADS, it wil be moved to the
right area automatically depending on how you have your file area
links set up. You could simply specify PCB-PPE for both this and
the above option, in which case files inbound for PCB-PPE get
placed in the file area PCB-PPE and stay there. Please take note
of the magic words "NOWHERE" and "HOME" documented earlier which
apply to the file area "move to" field. They do not apply here.
You must specify a final destination area. Only file area
configuration uses those to distinguish where to move the file.
- Pass-Thru?
----------
If yes, this is a pass through area. In other words, inbound
files don't get moved into your file system. Any downlinks
receive files through this echo but you don't keep a copy. If
there are downlinks for a passthru area, their outbound attaches
and files are placed in the outbound directory and sent out.
Once sent, they are deleted and you don't keep a copy on your
system.
- Echo Out?
---------
This is a secondary security area for receive only file echoes.
Say you receive a national file echo off the backbone, but you
cannot hatch files into that echo. Setting this option to "N"
will guarantee this area will not echo files out of your system
at all.
- Description Options
-------------------
You may select TIC file descriptions as the imported decription
or you may use the description from the file id file.
- Origin Line Selection
---------------------
The origin line that will be used by the announcements feature
for this area. Select any one of the 50 available origin lines.
This is a number from 1-50 so if you change the contents of say,
origin line 7 and you had 7 selected, the new value will always
be used.
- Keep Requests?
--------------
Set to "Y", this will keep a copy of all File Manager requests
submitted by other nodes. This is usually set to "N".
- Keep Receipts?
--------------
Set to "Y", this will keep all receipts generated for downlinks
submitting File Manager requests. More on the File Manager in a
following section.
- Announce?
---------
Should we announce files when they come into this echo?
- Traffic
-------
This opens up another small window that holds information about
file traffic for this area. Here are the items in order...
- Files In
--------
Number of files that have come through this echo area. This
value does not include hatched files.
- Files Out
---------
Bytes that have been exported or "downlinked" to other nodes
from this area. This value does not include hatched files.
- Bytes In
--------
Bytes that have come in through this area from your uplink.
- Bytes Out
---------
Bytes that have been sent out or "downlinked" to another node.
This value does not include hatched files.
- Hatched Files
-------------
Number of files hatched from your system into this echo area.
This value does not include Files Out or is not include in that
statistic.
- Hatched Bytes
-------------
Number of bytes that your system has hatched into this echo
area. This value does not include the value showing in the
"Bytes Out" field.
- Delete TIC?
-----------
This will enable the deletion of inbound TIC files. Normally
this is always set to "Y".
- Delete Attach?
--------------
This will enable the deletion of inbound attach files.
Normally this is set to "Y".
- No Delete
---------
Gaurantees that this area will never be packed out of the echo
database.
1.2.16
Echo Area Global Menu (Alt-G)
-----------------------------
When in the echo area menu, you have another sub menu available
to you called the global menu. Here we will describe the commands
on that menu. They are meant to simplify large changes in node
configuration etc.
- Add Node
--------
Here you can add a node to your lists. You will have to specify
which folder you wish to process, then Base Runner will add this
node to all areas that belong to that folder. You will also be
given the opportunity to specify the nodes link attribute,
whether it is (S)end, (R)eceive or (B)oth.
- Delete Node
-----------
As above, except that here you are deleting a node from a
folder. Attributes do not apply here as the node is being
deleted as well as their attribute.
- Change Node(or change a nodes attribute)
----------------------------------------
Here it is a little different. The same applies to the fact that
the node is affected if it is in the folder you specify, but
here the node number gets changed. The options for that node are
still the same. How you would change a nodes attribute but not
the actual node address is by specifying the same address for
the "Address to Change" and "New Value". That way only that
nodes attribute is changed. We don't know if this is terribly
useful to anyone other than the large hub, but we included it to
have a full spectrum of capability.
- Aka
---
This is where you may select the akas you wish to represent
yourself as. You may select as many as you wish here.
- Message Base
------------
When a file comes in, you may announce its arrival into a PCB
message base. It may then be echoed out or sent out via netmail
if the area is configured as such in PCB. This allows you to
select that conference by reading directly from your PCB config
- Initial
-------
This is the initial file area the file will be placed into.
- Owner
-----
This is the owner(or final filearea) of files entering this
area.
- Change Origin Line
------------------
Same thing here except that you are changing the origin line
for a particular folder only. The changes are reported and you
are then asked to press a key to continue.
- Announce
--------
This is the announce message (containing message text with -
possible macros) text file that will be inserted into messages.
Please read section regarding Message , 1.2.15, for more details.
- Toggles
-------
Toggles are broken down as follows and are documented in
detail under echo area configuration.
- Passthru
- Echo out
- Keep Requests
- Keep Reciepts
- Announce
- Delete Tic
- Delete File
- No Kill
- Downlink Original
for more information on these toggles, please read 1.2.15.
1.2.17
A Note about Downlinking
------------------------
It should be mentioned how Base Runner deals with downlinking.
Because most systems require you to constantly repack your bases
in order for you to add more nodes, it creates ALOT of extra
unneeded code and slows the program down extensively. This is
not the case with Base Runner. A set record size allows us to
run at a MUCH faster speed but offers a set of problems when you
want to downlink to more than the 250 nodes per area provided.
So to get around this, once you have filled in one areas lists
for downlinking, just create another area with the same name.
This second area can clone the first(except the nodes) or be
totally seperate, allowing you to deal with the second set of
nodes differently than the first. We believe this to be a
feature rather than a bug as it allows more power in your
configuration. We have yet to find practical uses for it but are
sure that there are some ;) This way unlimited nodes downlinked
are made possible. It would be a VERY busy system who downlinked
to more than 250, though, so we think this may not in fact
become an issue, but we covered the bases(pun intended) anyways.
1.3.0
Downlinking and Hatching
------------------------
Downlinks are nodes that you supply files to. When you first
enter the File Echo section of configuration you get a horizontal
list of all the areas you have defined. Pressing ALT-L on any
area will bring up a downlink list screen where you can manually
add or remove nodes receiving the area.
There will be two windows appear. The windows on the left is a
scrollable list of the nodes you defined in Node Information.
Pressing the spacebar on any node will add or remove (toggle)
that node in the window on the right, which is the current list
of systems receiving that area. You can specify up to 250
downlinks. Note that your uplink can go here also. Some entries
are added automatically by the File Manager as it processes
requests from your downlinks. Note also that a node must be
defined under Node Information in order to be added to or removed
from this list.
File hatching is a process by which you submit a file into an
echo. For example, the local net here has a file echo called
FILE_REQ. It's used throughout the net for the distribution of
each system's master file list. If I wanted to send out my file
list to this echo, I would Hatch the file.
Hatching or submitting a file into an echo is done through both
the auto echo function as described earlier and using BrUtil, a
utility provided for doing all kinds of things including this.
BrUtil is documented here.
1.3.1
Using BRConfig, Base Runners Configuration Program
--------------------------------------------------
Using BRConfig is very simple and there is but one command
line switch available to you that is used as "EGA". This tells
us what video mode, VGA or EGA or quiet, you like us to run the
program in. This may help for some incompatible system that do
not also support direct screen writes. You may also configure the
video mode in the program itself.
As far as the command lists available, we will go over them
with some detail but need to break them down somewhat to
simplify their structure. Listed in the following order...
1 - Nodes DataBase,
2 - Files(or BBS) DataBase,
3 - Echos(or TICS) DataBase.
1.3.2
- Command List for the Nodes DataBase
-----------------------------------
Alt A or Insert
---------------
- Adds a record to the database. The record will be
automatically added at the end of editing if you select "Y" to
the prompt "Save Changes?". You are put into an editing dialog
where you may leaf through the fields to select and/or input
the various data items you will need to edit the node that the
selection bar was on. There are two fields, or at least they
appear to be input fields that are not fields at all. These are
on the screen to indicate that there is "More..." when you hit
that portion of the editing. Rather than clutter up your screen,
certain specific items were grouped together into these "sub"
dialog boxes to give you a clearer view of what exactly you are
editing. When you see the new box pop up, you may cursor through
th fields but there are two you may not actually edit. These are
the Total Kbytes and total file fields. These are actually not
fields but rather the totals calculated from the existing
totals. Change one of your total values and watch these two
fields adjust themselves. So with this, it is easy to explain to
you that there is no editing and any attempt to "get" to those
fields will fail.
Alt D
-----
- Deletes the current record from the database. The record
does not physically get removed but rather "tagged" as deleted.
When a record is marked in this way as deleted, the color of the
selection bar changes to indicate the deleted status. The
records do not get physically removed from the disk file until
you use the "Pack" function(explained shortly).
Alt G
-----
- Invokes the Global menu. Here you may do various operations
on a global basis, making large edits much easier. Please read
the section covering the global menu for more details.
Alt H
-----
- Shows a help screen with this command summary on it.
Alt L(or spacebar)
------------------
- Invokes the uplink list editor. A list of up to 15 lists may
be edited here by simply moving the cursor to the desired
selection and pressing enter. Dots will appear as the background
to the editing field to indicate that you are actually editing
the field. If you press the spacebar or a key before any other
cursor keys, the field will automatically be blanked out and the
character you used is now the first entered character. This can
work for you or against you but getting used to it will aid you
in becoming a "power" user.
Alt P
-----
- "Packs" out the database possibly removing records marked
for deletion. Keeping a lot of deleted records can actually slow
down Base Runners operation as the fewer the nodes it has to
maintain the better. This is not, however, usually much of a
problem unless you have more than 5000 nodes on the average in
your database.
Alt S
-----
- Search operations. You will see a box pop up. If you have
already entered a value prior to this execution, that value is
the default. This makes repeat searches quick. Pressing Enter
will accept the default value or you may edit a new value which
will become the new search criteria. This value is used to
compare against the sysops names in the database.
Alt X
-----
- Immediately exits the program unconditionally. All files are
saved and you skip returning to the main menu, you are dropped
to DOS immediately.
Regular Ascii Characters/Numbers
--------------------------------
- You may also press any letter or number key to quickly jump
you to the first record of that letter/key. If an sysops name
starts with "A" as in Andrew, pressing the letter A will put you
at the top of the "A's". It is usually very easy to page or
control page to the desired record using both of these methods
allowing very powerful editing features.
- Command List for the Files Database
-----------------------------------
Alt A
-----
- Adds a record to the database. You will be automatically put
into editing mode and will be able to input to any field you
wish. Please read configuring Base Runner for more details on
these fields and what they are for or simply press F1 at just
about any prompt for a complete help system.
Alt D
-----
- Deletes the current record from the database. As with the
nodes and echos databases, the record is not automatically
deleted but rather marked for deletion. Pressing this key again
will unmark a marked area reversing the above. The records do
not actually get physically removed from disk until the Pack
operation has run its course.
Enter
-----
- As with all the databases, pressing enter will always put
you into editing the current selection. This input screen will
be the same one you will see for adding areas except that the
current selections area values are loaded up as the defaults.
Alt G
-----
- Invokes the global menu. There you may perform various
operations on the database possibly affecting many records with
the same default value. Please read section on the files area
global menu for more details.
Alt H
-----
- Shows the general help screen. Here you may browse the
command summary. More specific help topics are available in the
specific fields editing dialogs as you need them.
Alt I
-----
- Imports from PCB bases. This very powerful feature has to be
set up in order to run properly. A valid PCB envoironment
variable must be found in your envoironment. For networks, this
must be a regular DOS path, not the specific networks pathnames,
for example... //NODE-1//D-DRIVE// . This will not be recognized
by Base Runner but E:\PCB will be recognized. This directory is
scanned for PCB's configuration files and if found, your DIR.LST
files are scanned for all your configured areas and only the
areas not already in your database are shown on the screen for
you to select. You may select as many or few as you like for
importing. The DIR file spec is the field used to compare an
area to see if it is already in our database. The new areas are
created using as much of the information that is available as
possible from the PCB configuration. You will have to still go
in and edit specific information on these newly created areas.
Afterwards, your database is rebuilt and reloaded and you are
back in editing mode with these new areas at your fingertips.
Alt L (or SpaceBar)
-------------------
- Pulls up the links dialog. This is a box with some editing
fields in it. These fields are also available in the main
editing window but are available here as an aid to those "quick
and dirty" edits. Only links information is included here.
Alt S
-----
- Search Operations. As with the nodes database, this feature
can be used as a repeat search by simply pressing enter to
accept the default you had already entered, or reedit a new
value into the field and press enter, making that the new
default. This value is compared against the area names for a
match and if found, you will be taken to the found record.
Alt T
-----
- Invokes the "File Movement Trails" dialog. This is a handy
way of monitoring the chain of file areas that this area is
connected to. All records are scanned for connections via the
"move to" fields in your files database. File movement and the
areas that are in a particular chain can be quickly spotted.
Only from the current selection down is included in the list. If
an area feeds this one(many areas may in fact do that) it is not
included in the list, only from this one until its final
destination point or an area with the "NOWHERE" field. Either
one will stop the "linking" process. Up to a maximum of 1000
links are listed. Be careful of infinite loops, a group of areas
that are going in a circle. This command helps you in spotting
those types of problems.
Alt X
-----
- Unconditional Exit. All configuration files are properly
updated and closed and you are immediately dropped to DOS.
Regular Ascii Characters/Numbers
--------------------------------
- You may also press any letter or number key to quickly jump
you to the first record of that letter/key. If an area name
starts with "1" as in 1-BUSI, pressing the number 1 will put you
at the top of the "1's". This is the same for any keyboard
letters. It is usually very easy to page or control page to the
desired record using both of these methods allowing very
powerful editing features.
- Command List for the Echos Database
-----------------------------------
Alt A
-----
- Adds a record to the database. You will be placed into an
editing dialog and there you may input the data fields. Each of
these fields have help by pressing F1.
Alt D
-----
- Deletes the current selected record from the database. The
record is not physically removed from the disk until the Pack
operation has ran its course. The record will change color on
the selection screen to indicate that this selection is now
marked for delete. By pressing Alt D again or on any area marked
as deleted will reverse the mark and undelete the record. Of
course, you cannot undelete records from a packed database.
Enter
-----
- Edits the current selection. Here you may input or change
values for the current selection. The same input dialog is
provide here as when you add a new record except that this areas
defaults are all in their proper fields.
Alt G
-----
- Invokes the global menu. There is a variety of global
database changes that you can use from this menu. The
operations on this menu are explained in more detail in the
configuration section.
Alt H
-----
- Shows a screen with a command summary similar to this one.
Pressing escape will abort this dialog.
Alt L
-----
- Allows viewing/editing of current node connections to this
echo area. Here you may add or delete nodes or change their link
status.
Alt P
-----
- Packs the database permanently removing the records marked
for deletion. You are prompted and may turn back after pressing
this command.
Alt S
-----
- Search operations. The field that pops up in the dialog that
shows up when you press Alt S that has the default search string
in it. Pressing enter accepts the default and the search is
taken up from the location you are at in the database. You must
go to the top if you want to scan the whole base. This default
value aids in repeat searching.
Alt X
-----
- Immediately cleans up the configuration files and exits the
program unconditionally.
Regular Ascii Characters/Numbers
--------------------------------
- You may also press any letter or number key to quickly jump
you to the first record of that letter/key. If an area name
starts with "1" as in 1-BUSI, pressing the number 1 will put you
at the top of the "1's". This is the same for any keyboard
letters. It is usually very easy to page or control page to the
desired record using both of these methods allowing very
powerful editing features.
Edit Fields Pointing to Text Files
----------------------------------
- Most of these fields support an F2 command which will, if
configured for an external text editor, will invoke it allowing
you to directly edit these files. Please note that with fields
that do no begin with the % symbol (which denotes only a single
file or comment) will be ignored by this command. It will only
work on valid DOS files. No checking is done for binary or text
mode during this shell.
1.4.0
BRUtil - Base Runners Utility Program
-------------------------------------
A Utility Program called Brutil is included in the distribution
archive. This program is designed to do all of Base Runners
maintenance events. There are two ways to invoke BrUtil. One is
via command line(registered copy only) or you may use the
interactive version with an easy to use menu system and built in
help system. Please note that although the command line version is
fully documented here, it is not available in the evaluation copy.
To invoke Brutil you may simply type in the name of the program
or run it from the command line. The command line version is only
available in the registered version but is covered here. We will
go through it from the top down in the main menu of the program.
You may use your mouse to navigate through the menus. The only
time the mouse is not active is during input operations as in
Hatching, Notifying etc. In the command line version, you can
string as many commands together as you like provided they do not
exceed 127 characters in length in total.If this is the case, you
will have to invoke it again with the new commands. An example
would be...
BRUTIL INDEXES PACK NOTIFY NOKILL .....
BRUTIL DELETES ...
1.4.1
- Pack FileBases
--------------
This instructs Base Runner to read your index file one at a time
for each area and copy its attached record from the main base into
a temporary base in order, skipping the deleted records and
compressing your bases reclaiming disk space as well. The fallback
to this operation is that you can no longer recover lost records
by rebuilding the indexes. This happens due to programs like Base
Runner deleting records indexes but not the main record in the
base. We did this purposely to allow data recovery options in the
future and to allow more flexibility in the function and use of
it. Of course this requires you to know a bit more about what is
taking place with the package but will afford much more power
overall. Command Line Syntax...
BRUTIL Pack (case is not important)
This operation is not quite as quick as the others as it is the
most disk intensive operation in BRUTIL. Please note that if you
are trouble shooting a corrupt base, this is NOT the first course
of action to take.Please read section on FileBase Troubleshooting.
1.4.2
- Build Indexes
-------------
The only time you would ever need to use this feature is if you
were trouble shooting a problem with one of your bases or if you
wished to recover some deleted files. In either case, the command
line syntax for this operation is ...
BRUTIL INDEXES (case is not important)
This operation will go through the filebases one at a time
checking each record and recreating an index for that base. Note
that you will now have possibly many more files in your base than
when you started because the main Base Runner program , when
deleting records, deletes only the index record, leaving a "hole"
in the filebase. The trimmed index is lost in lieu of this newly
created one but if in fact you had a corrupt index(an index is
corrupt when BREDIT shows nothing but garbage and possibly locks
up when in an area) this is favorable because you can now delete
the records instead of losing the whole base. A few examples of
why you would need this feature are power loss with a disk cache
running, disk fat problem, network crash etc.
1.4.4
- Duplicates
----------
Because some files come through more than one file echo
sometimes, it is hard to define what is and is not a duplicate,
so with Base Runner, a duplicate can only be defined on a binary
scale. This means that simple filename duplicates are not
enough. We must also include a binary representation. There is a
way to check each character against a table to see if it is the
same as another file. This CRC type of calculation on a file is
a very good method and although it may take a little bit more
time, it is well worth the security you attain by using it. One
problem, however, is that even an identical file may be sent(as
mentioned above) to two different areas. Because of this, only
files that share a single base that are identical are checked by
Base Runner to ensure proper operation. This feature of Base
Runner goes through each base and if it finds both an identical
filename and an identical file on a binary level, it will remove
the oldest copy of this file. If more than two exist, the newest
copy is maintained. The arbitrary system used here is only to
accomodate the command line nature of this utility but will not
be limited in further consideration of how this operation should
be handled. Command line syntax ...
BRUTIL DUPES
1.4.5
- Dupe Trim
---------
There is a number you may specify in the configuration program
under System Info for the number of dupes to maintain in the
database. Since this is not a critical routine, an event
periodically will suffice in maintaining this base. The base is
trimmed to the number in the config. Only the latest x files are
kept. The rest are lost and are not recoverable.
1.4.6
- Notify List
-----------
Available in both modes of operation, this command tells Base
Runner to go through each of your node entries and if they are
toggled for notification, they will receive a netmail message
generated with the default message flags you specified for that
node with the areas they are configured for. That way they may
compare that list with their own to see if they have a current
configuration or a configuration that is identical to yours.
Command line syntax ...
BRUTIL NOTIFY
1.4.7
- Hatch File
----------
On the main menu of BRUtil you are prompted for a
path/filename to hatch, followed by a file to replace(optional)
and then you are asked for an area to hatch to.Base Runner will
then go through your areas until it finds the file you want to
hatch. If it is found, it is file attached to all nodes that are
currently configured for that area. The packet status is set to
what you have set up for each particular node. An accompanying
TIC file is sent along with the attach file to that node with all
the info needed for that node to process that file into that echo.
Your password is included in that TIC file so be sure your
passwording is set up properly before using it. Please consult
with your local hub for info on whether they wish you to use TIC
passwording.This is a personal preference but is comming into use
more and more as security becomes more of an issue. In the command
line mode, the syntax for this feature is ...
BRUTIL <PATH/FILE> <AREA> (no brackets, case insensitive)
- presently ,the replaces field is not supported in the command
line version.
1.4.8
- Send File
---------
This is similar to the above feature in that it sends a file
to a downlink. There is one difference here. This operation does
no checking to validate a node, it simply does what it is told,
sends that file (if it exists) to the node specified and does not
warn you if the node does not exist. This is intentional as Base
Runner assumes you want this ability and will not bother you
much about it. Please note that because this file is not being
"hatched" nor echoed, it will not have an attached TIC file with
it. On the main menu, you are prompted for a filename and then a
node number. In the command line mode, the syntax is ...
BRUTIL SEND <PATH/FILENAME> <NODE#>
... node number can be any node number as long it is a valid
format and filename must be a valid path and file or Base Runner
will drop out and let you know it was not succesful.
- Get+
---
A very handy utility for "fetching" files from another system,
whether or not they are in your nodes database. The syntax is as
follows(if you are registered user with command line)...
BRUTIL GET <FILENAME> <Z:N/N.P> <PASSWORD>(optional)
... node number must be a valide Fidonet address(point number
is optional) and the password is optional. This does not update
the nodes database with file stats as it is considered to be a
"Raw" utility to aid in those times when "Quick & Dirty" is the
matter of business.
1.4.9
- Init Bases
----------
This would usually only ever be run once, but was left in this
utility program because it was thought that once a new area was
created, you may want to go in and readopt the area into your
filebase. This feature will go through the DIR files specified in
the areas configuration and recreate your filebases with the
descriptions found in the DIR file. Some other info is processed
such as the CRC of the file but no file adds, file ids or any
other processing is done. This is for speed reasons and because
you may not want all your files on your system reprocessed. You
may also use this feature to bring a new area into your Base
Runner system that wasn't there before. For example, you already
have 20 areas on your system, but you want to import and start
using a few more. Simply set up the areas for them with the new
directory and DIR file name in BRCONFIG and then go into BRUTIL
and run this operation. Please note that this may take a long time
depending on your machine type, number of areas processed, number
of files processed etc. Whatever you may have had in any existing
filebases are lost permanently after this feature is run.
1.4.10
- Build CRC
---------
This will go through each of your areas and build a CRC table of
your files and add them to your duplicate database. This will, of
course, delete any existing file info you have. The reason for
this is if you lose your dupebase or corrupt it in DOS for
whatever reason. This way you can quickly come back and re-build
all the files that are on your system. 8 bytes are stored for each
file that is in the base, so size should not be a large problem,
but if it is, you may go into BRCONFIG in system info and change
the dupe limit to reflect a lower number which will save some
disk space, exactly 8 bytes per file managed. This base is
automatically trimmed by the Trim feature, so after you have a
valid base, you should never have to run this operation again.
1.4.12
- Auto Unlinking
--------------
Sometimes every node will unlink themselves from one of your
areas and you will not notice that you now have an area hooked up
to your uplink that may not be necessary. What this operation does
is generate a message to your uplink disconnecting you from that
area so that it is now a "dead" area. The record is marked as
deleted but NOT removed from the database, you can do that with
the "Pack" routine in BRCONFIG's editor. That way you can also see
which areas have been removed. This can of course be overriden so
that it remains connected by setting the appropriate toggle in the
main config using BRCONFIG->File Echos->Edit->No Kill, which will
override anything this operation may want to do.
1.4.13
- About
-----
This is just some information about the program, copyrights,
mailing address for CompuData etc. It is of no importance other
than to flag the program and its copyrights without having to
pester you with it all over the program.
1.4.14
- History+
-------
A very handy report that includes all the information you need
about file activity. The number of days specified in the main
configuration is used. The reason for this is that the file is
automatically trimmed to that number of days. This command is
available only from the command line and not in the main menu;
1.4.15
- Dirs
----
Sometimes if you make changes in BREdit or if you are not
happy with the formatting of the DIR file or for whatever reason
you might have, this feature will allow you to regenerate either
one or all of the filebases for the BBS (either the DIR file or
the Files.BBS file). In the full screen mode you are guided
through the inputting of the areaname to regenerate (if just one
area) after which the area is recreated and placed into the
specified directory for that area. In command line mode you must
enter the syntax as follows...
BRUTIL DIRS OFFLINE
or you may also use the magic word "ALL" to denote that you wish
Base Runner to regenerate all of the DIR files(or Files.bbs).
BRUTIL DIRS ALL
How long this process takes depends on how many file areas you
have. Also, all the headers and footers are regenerated
accordingly, so if you made changes to those files(the templated
text files with the macros in them), they are regenerated at
this time. If you simply made changes to the final header or
footer and not the original template file you do not have to
regenerate the attached file areas DIR file. The reason for this
is that the DIR file only uses the %PATH/NAME to point to the
generated file in your headers directory and does not include
the actual parsed text.
1.4.16
- Exit to Dos
-----------
Drops you back to the operating system giving full control back
to the calling batch or command line. Cleans up its config
updates before it exits.
1.5.0
Using BREDIT, Base Runners FileBase Editor and Utility System.
──────────────────────────────────────────────────────────────
Base Runner Edit or BREdit for short, is Base Runners Filebase
editor/utility program. It is very much like PCBFiler only for the
reason of familiarity. We are not here to alieniate PCB sysops, we
try to blend in as seamlessly as possible, so the interface is as
much like that program as possible and is in no way intended to
"Rip off" Clark Developments PCBFiler program, only to try to
emulate it, well.... almost .... as you will soon see... we have a
few extra things we think you will enjoy. Such things include a
full two way file id system. This means that you can insert a file
id file from the archive into your filebase as the description,
hence the generate DIR files will have the file id file in them as
well. The other way is to take the description currently in your
filebase and insert it into the archive as the archives new file
id file, replacing any existing file with your new copy. Move,
Copy, Delete, Hatch, Edit, DateStamp, Abandon and Viewing are just
some of the features of this very powerful editor. Now we will go
over the main function of the program with the system requirements
first, stating how much of the config is necessary before proper
operation is obtained. A very handy interface with very elegant
colors and fonts are provided and full mouse support makes this a
very easy to use system.
1.5.1
- Requirements
------------
You will have to make sure you have properly configured Base
Runner before you may use this program properly. Fist, you must
have valid Files Areas defined with valid paths (config will let
you know while editing if the path is not valid and prompt you to
create it if necessary). Also , you MUST have a "BAD_FILES" record
so that any failures in the file processing will ensure BREdit can
move the file offline to this area. A valid filebase path in
system info and a valid filebase path for each of these areas must
also be defined if you wish to find the data files for that area.
You might also want to make sure that you have an editor defined
in BRConfig (system info->Paths). You may specify any editor that
takes a filename on the command line. Other than that you are on
your way.
- Initial List Dialog
-------------------
This is the initial entry point in the program. It supplies you
with a list of your file areas. You can be anywhere on your system
as long as this program is in your path, so these areas files can
be found because they must remain in the home path of the program,
or reside in the same directory as BREdit. This list box has full
mouse support so that all you have to do is point and shoot, or
you may move your cursor down to the area you wish and press
enter. If you are using the mouse, you must press enter once to
drag the hilight bar on top of the area name and then a second
time to actually tell BREdit to load up that areas indexes and
display it and then leave you in edit mode. Whenever you exit an
area, you are placed back into this dialog so you may select the
next area or press escape to exit or the right mouse button.
1.5.2
Command Summary/Status Bar "Hot Spots"
--------------------------------------
- Alt A - Add File Id File
------------------------
If the hilight bar is on the selection you wish to operate on,
you may press Alt A or if your mouse cursor is on the the Alt A
text on the status bar, you may press the left button to invoke
file id addtion operations to that file. Please notice that it
does not just "run right in" and do it, it simply marks the record
for that operation. You will see an "A" on the left side of the
files box. This operation will be performed when you try to exit
tihs area. At that time you will be prompted on whether you wish
to save your edits or not. This operation will take the
description you have entered and replace whatever file id exists
in the archive with it as a valid file id file. If one does not
exist, a new one is added.
- Alt B - Abandon File
--------------------
If you wish to delete a filebase record but NOT remove the file
from disk, you may abandon the file. The actual file that this
record belongs to is removed. Please note that if you do this and
the file area is set up for auto adoption, this file will be
adopted into this area automatically the next time that the main
Base Runner program is executed again, making this edit useless.
The reason for the adoption is so that in case other programs
simply "COPY" files into that directory, we can immediately pick
them up and put them into our filebase for that area, making this
a "real time" , static style files system which is current up to
the second.
- Alt C - Copy File
-----------------
This will take the filebase record AND the file and copy it to
another area. You will be prompted for the area to copy it to with
a dialog box of areas available similar to the main file area
dialog box so that you may select which area to send it to. You
will see a "C" on the left side of the screen appear signifying
the area number that this file will go to. There is not enough
room for the areaname, so the number will have to do for now.
- Alt D - Delete File
-------------------
This is similar in function to Alt B, abandon file, except that
with this operation, the file is deleted from disk as well. BREdit
does not handle file recovery or undeletes(yet!) so be sure you
want to delete this file permanently.
- Enter - Edit File
-----------------
A new dialog box appears if you press either that area of the
screen with the left mouse button or the Enter key. You will by
default be in the description editing window. This is because
the speed users will want the fastest way to get to the text
editing window. The filename and the filedate may also be edited
here. A very simple full screen editor is supplied although we
are considering allowing "Plug in" editors for this purpose,
allowing you to plug in such editors as Qedit(C) so that you may
be more comfortable with your editor. There are a couple of new
commands available to you in this dialog.
- Alt I - inserts a blank line at the point of the cursor.
- Alt D - Deletes the current line.
- Enter - Splits the current line if not on left or right.
- Escape- Ends edit session, you are prompted for save.
You may also edit the filename or the filedate. Move your cursor
to the field you wish to edit and simply edit the field. This is
all keyboard input, there is no mouse support returned again until
after you press the Escape key. Please read 1.5.3, Editing a file
entry for more information.
- Alt F - File Id Add
-------------------
This will instruct BREdit to take the file id file, if one
exists in the archive and inserts it as the new description in the
filebase for this entry. The DIR files are not regenerated until
the next execution of Base Runner, so it is a good idea to run
Base Runner through after edits of this nature are done. In future
versions, this will all be internal to BREdit.
- Alt H - File Hatch(+)
---------------------
You can now hatch as many files into as many areas as you like
right from BREdit! You can even hatch all selected files in one
quick step to one area at a time, making this a VERY powerful
feature of BREdit. You can also hatch from DOS with BRUtil. When
you press this command you will be prompted for an area to hatch
this file into. If you had more than one file tagged or selected,
you will first be prompted whether or not you want to hatch THIS
file ("N") or all selected files ("Y"). If you select all files,
BREdit will prompt you for a file area and once selected, all
files tagged or selected will become unselected and they will now
become marked as H<areanum> on the left side of the edit window.
Afterwards, when you exit the edits for this area, you will then
notice the actions BREdit takes to hatch the files out. It will
create an attach message and an appropriate TIC file to all the
downlinks and uplinks currently connected to this area. BREdit
will also mark the file as NOKILL so that it cannot be moved until
after it has been sent out to all the nodes currently set up to
received it. After all nodes have received the file, the next
running of BRUtil NOKILL will clean up the no kill markers on
these files.
- Alt I - Info
------------
This will bring up a dialog box with some important information
about this areas setup. Here you may see such things as Dos
Path, Message Base Path, Add File Path and Name, Delete FileName
and path, Days Old before files will be moved, where to upload
files for this area to and where to move files after Days Old has
been reached. If you are confused about what any of these do,
please look under BrConfig for more details.
- Alt K - No Kill
---------------
Marks the file as No Kill, meaning it will not be moved nor
processed in any way until this flag is removed. Normally Base
Runner will deal with this flag internally and should not normally
be used by you, but there are times when you need to toggle this
so it is available. If you have any files selected, you will be
first prompted to see whether you want to mark just this file or
all selected files as No Kill, you have the option. You can leave
all the selected files selected but just mark this one or you can
answer "Y" and mark all files selected in one quick keystroke.
Left mouse button is the same here as pressing "Y" or Enter during
this prompt.
- Alt M - Move File(s)
--------------------
You can move files around the areas quite easily using BrEdit.
You can move just this file or all selected files exactly the same
way you do with copy except that this does not leave a copy of the
file in this base, only a copy in the destination base. You may
still abort this operation when you exit from this areas edits by
pressing "N" to the "Save Edits" prompt. Escape or the Right mouse
button will do the same thing. Please remember that unlike
PCBFiler, these files are moved right after you process this
area.
- Alt N - No Show
---------------
When the DIR files are generated for your BBS, you can choose to
skip showing all of them by setting this toggle on for the chosen
file. This file will then not show up in the PcBoard's file areas
but will actually still be there in the directory.
- Alt O - Owner
-------------
Normally, when a file comes into the system, it will have a
default behaviour connected to that area. The problem with having
just this is that it is not flexible enough. You can mark files
seperately here with alternate ownership. This means that a file
normally marked as "PCB-UTIL" for ownership, which would normally
send its files after 30 days(this is all example) to OFFLINE that
is now changed to "PCB-QWK" will now go to that area when it is
done (OFFLINE) but when it is finished going through the areas(or
if it comes into an area that sends all its files HOME) it will
then wind up in "PCB-QWK". Please don't confuse this as the NEXT
area the file goes to. The file will still go from here to the
next base this area sends it to but when the file gets to the last
directory in the chain, that base should become its home.
- Alt S - Select
--------------
This will "Tag" or select the current file. You can select as
many files as you like for use with other features such as Copy,
Move, Hatch, No Kill etc. If the file is already marked, it will
be unmarked, if it is not marked, it will now be marked. You will
see an "S" on the left hand side of your screen beside this files
entry. Pressing the left mouse button on the status line on all
items will activate that command. Exiting edits for this area will
lose all selected markers.
- Alt T - Touch FileDate
----------------------
You may "touch" or change the filedate of the file without
having to go into the edit window if you want to change the files
date to todays date. This is known in DOS as "touching" the
file(please consult DOS manual under touch). You can also change
the file back to the original date if you have not yet exited the
edits for this area if you change your mind. The reason for this
is that we actually store two dates while in edit mode on each
file, so the original is still maintained and can be restored but
be warned that after you leave this base you will not be able to
undo a touch.
- Alt V - View Archive
--------------------
This will activate an archive viewer which will look into the
archives, if this is an archive and list the files in the main
file window of this archive, prompting you to press enter after
each screen full of files and then one final enter when the last
screen is done, returning you back to the main edit window.
- Alt X - Exit Program
--------------------
This instructs BrEdit to exit immediately, NOT to go back to the
main area selection dialog. BrEdit will not perform any of the
edits and you will lose them. You may also press the litte square
yellow box on the main edit window borders right side to exit
immediately.
- Other Commands
--------------
There are four arrow keys on the right hand box border.
These are "hot spots" for your mouse cursor to use. If you press
the left button on either of the inner arrows, you will scroll up
a page or scroll down a page of files. If you press the outer
arrows, you will go to end or home and the same behaviour as the
home or end keys will kick in. The home key when first pressed
will take you to the top of the current page of files but if you
are already on that top line,you will then be taken to the top of
that areas list. The end key works the same way,if you are not on
the bottom line, you will go to the bottom line, but if you are
you go to the bottom of the database or list.
1.5.3
Editing A File Entry
--------------------
There are a couple of things to go over here, as well as some
minor gripes ;) If you press Enter, as mentioned briefly above,
you will see a new pop up with some items in it. Your cursor will
automatically be in an editing window, pressing any key on your
keyboard will affect the description for this file. You may edit
just as you would with most editors, but please understand that
this is a *very rudimentary editor and is not meant to be a power
editor such as some of the markets finer editors are. It is with
that idea that we allow you to use whichever text editor you feel
comfortable with, so long as it allows Base Runner to pass a file
name to it on the command line. Edit.com that comes with DOS is a
good example of such a program. If you use one of these editors
that allow you to use such commands as "Save As", please use the
default of temp.dat as the file name. In other words, please just
save the file and not necessarily save it to an alternate filename.
In order for an external editor to work properly, one must be
declared in your config program, BRConfig, under system info and
under paths. There you will find a field called Ext. Editor. This
field takes only the name of the editor(along with the extension
of .exe if you wish, it speeds up Base Runner) and not the full
path.If you have room and wish to put the path, that is all right
too, but we suggest you place the editor in your path and let us
find it for you when we need it. You will be prompted on whether
to save the new edits or not,but only if you have made changes to
it. Base Runner is smart enough to know if you have changed the
description file as long as you save it to our default name of
temp.dat. That takes care of the external edit, except for one
thing. If you want the extra editing features of the editor that
is internal, you may wish to still use the enter key to get into
that section. There you may edit the filename, filedate or even
the date the file entered this area via a file movement. Status
is shown on the left hand side for the current file.
1.6.0
Introducing Base Runner File Request System or BRFREQ
─────────────────────────────────────────────────────
- Description of File Requesting
------------------------------
File requesting in this concept is totally unlike the commonly
referred to term of file requesting. Unlike Fido style file
requesting, this is not intended for sysops to exchange files via
their mailers. This is a system that does in fact use your mailer
or front end, but uses it to transfer files back and forth for the
benefit of your users. There are many ways to attack this type of
situation and we are constantly changing this facet of the
package, but at this time it is a one tier system with direct node
to node contact, no hubbing is necessary. Because of the nature of
this request system, hubs are not needed and may in fact hinder
the efficiency of the overall system. Ok, enough of that, lets
find out what this is all about. If you and another sysop or
sysops wish to have their users have access to all the
participating systems file areas via an online door, all you need
to do is specify that node in your configuration as file
requestable, set up a couple of simple things to accomodate the
file flow and you now have an automated system for your users to
request files from any other BBS involved. Setup is a breeze and
you can limit other systems amounts or just put a cap on what they
can take daily to keep a "lid" on how much is going out.
In more technical terms...
BRFreq is designed to allow your users(and you as sysop) to
request files from other systems. Only systems found in the
nodes database may participate. Users and/or sysops of these
systems may only request from your BBS areas (File areas) , not
from TIC (echo) areas as these areas are only to point to an
existing BBS area anyways. Each generated netmail message to
that system has to have a valid password on the subject line.
One file per line must have the format of ....
REQUEST <AreaName> <FileName>
... on it. At any time in the netmail message there is a
tear line(---) found, the message parsing is aborted and nothing
after that is processed(handy for notes etc...). This format of
generated netmail message is by default created by BRFREQ when
you "flag" files from the board. When a user enters the door,
the door first looks up all netmail messages and puts existing
requests from that person back into its batch queue. It then
removes those messages from netmail area. When the user has
finished flagging or editing his/her batch of files and tries to
exit the door, they are prompted on whether they wish to send
out the requests they have generated. If answered with a "Y",
then BRFreq regenerates the necessary attaches to the various
systems, providing appropriate passwords. You will find also a
LIST <Julian Date> line in each of these messages. This date
tells the other system the date of your last list update. If
this date plus the list delay in days is found to be less than
todays date, a new set of lists is generated for us and we then
not only recieve the files we requested but perhaps also an
update if the above criteria is met. You may also force an
update by putting in the line of UPDATE anywhere in a netmail
request. The file is then returned to us via regualar file
attach, but only after they decide that we have not taken more
than we are allowed for today. When the file is returned to us,
we scan the netmail headers in the request routine and find the
message. We then toss the file into the filebase area specified
for that node. If a seperate area exists for that node other
than your regular file areas, only files marked as user requests
will reside in that area. An optional announcement may be posted
if configured into the echo area tag specified for that node.
The other node, meanwhile, is keeping track of all bytes and
files they sent us and if at any time we exceed our daily
allowance (or 0 for unlimited), we will not get that file back.
After midnight, our node stats are reset and any new messages
waiting will then be processed again and sent out to us. This
causes a possible backlog of requests but is the only way to
restrict access to a node taking "too many files or too many
bytes".
That is the most technical way of explaining it. Please remember
that although this is primarily designed for users,sysops may also
generate request from their favorite mail editors, provided the
syntax is followed for generating such a message.
1.6.1
- Installation and Setup
----------------------
Installation was partly complete when you initially configured
your total Base Runner system, but some things need to be
addressed at this point. We will put this in point form for
simplicity and clarity.
1 - Make sure each node that is going to participate has a node
entry in your nodes database. That entry must have file requesting
toggled on (you will notice the edit fields are darkened if file
requesting is NOT activated systemwide from within System
Info->Global Options).
2 - Make sure that the directory in the nodes record is a valid
path. The config program will prompt you if you wish to create a
non existant directory.
3 - Make sure the nodes entry has a system name so that BRFREQ can
have a system name to display to the users.
4 - Be sure each system has a password set up.
5 - Send out a first intialization message to each system with the
proper password on the subject line and the lines ...
UPDATE
---
as the only text in the message.Anything after the --- is ignored.
This will initiate the request to get the updated lists from that
system. From that point on, list updating is automatic with every
request issued.
6 - Run your PcbSetup program and install a door entry into your
DOORS.LST file on your PCB system. Consult your PCB manual on door
installation. Specify the door to create a USERS.SYS file. Edit
your batch file (which at this point is still just a script until
it gets renamed by PCB at runtime) to make it look similar to the
enclosed BRFREQ sample file or you may use the BRFREQ file with
some edits to suit your system, number of nodes example.
7 - Make sure that your nodes are setup to security properly. For
example, if they have a security of 50 and most of the areas are
set up for 75, they will not see most of the system and will only
receive areas they have security for. Folders do not apply in this
situation. This security level is the main thing to consider in
allowing access.
8 - Test the door, make sure all the lists are accessible, if not,
check your paths to see if you have the lists there and the
control file. This control file is automatically included into a
ZIP when you receive the bundle from the other system. The main
program deals with all of the operations necessary to handle the
complete file requesting system. If the door simply locks up, try
specifying no shell in PcbSetup. We have found a couple systems
with limited memory have problems running under PCB when trying to
run some doors. This is supposed to be fixed as of v15.2 of PCB,
we have not seen it yet.
1.6.2
Configuring BrFreq
------------------
- BrConfig-> Requesting
---------------------
This is where you set up your screen paths and filenames and a
couple of general system toggles that deal with file requesting.
This section of the Configuration program was put here as it
directly related to this part of the package and did not need to
clutter up the main configuration options. Besides, this area is
quite small and easy to isolate and deal with.
- Paths/FileNames
---------------
- Path/Filename of Intro Screen
-----------------------------
This is the path and name of the first screen the user will see
after the copyright notice. There will be a delay to the user
after this screen of how ever many milliseconds you setup in the
following section. You may use PCB macros in this screen or any
ANSI sequences as well. RIP is not supported at this time but is
currently being worked on. A sample screen is included in the
distribution archive.
- Path/Filename of Main Screen
----------------------------
As above, but this is the actual main menu you wish the user to
see. This should include any menu commands that are available to
the user. For more information on these commands, read section on
using BrFreq. A sample screen is included in the distribution
archive.
- Path/Filename of Bye Screen
---------------------------
As above, but this is the last screen the user sees before
returning to the BBS. As above, PCB macros may be used in this
file and a sample is included in the distribution archive.
- Path/Filename of Help Screen
----------------------------
Same deal here, except that this screen should include
information about the functioning of the system, available user
commands etc. A sample help screen is included in the distribution
archive.
- Milliseconds to Delay after Screens
-----------------------------------
1000 milliseconds equals 1 second in real time, so this allows
you total flexibility. We were going to do it as simply seconds
but found that it was not enough control so we went down to
milliseconds and found that it gave us the ability to customize
the feel of the system. On screens that are scrolled this has no
effect. This is used after the intro screen and after the bye
screen and after certain non keystroked prompts.
1.6.3
Using BrFreq
------------
You will notice a familiar look when BrFreq is running. The
status line and controls are very similar to PCB itself. You can
drop to dos with the F5 command as well as F10 for chat. The F6
and other system critical routines are not available. The program
all runs off of a main menu which loads up a default system,
usually the first one at the top of the list and shows it as part
of the main menu command prompt. There are a set of commands that
are available to the user at this point. They are listed as
follows ...
- "B"atch Editor
--------------
Your users upon entry into the program have a batch built in
memory of the files they themselves have perhaps already
requested. This information is collected up by BrFreq upon start
up of the program and is in memory until the user quits back to
the BBS. At that time, the batch file is inserted into a file
request message to the various requesting systems but only if the
user answers "Y"es to sending the pending outbound requests. The
user sees a new sub menu and has a list of all the existing file
requests. The user can press "D" for delete entry at which time
they will be prompted for the number of the entry to delete. They
can also add a file. This command has a little twist to it. It
will not be limited by searching only the current systems files
areas for the files requested, they will search ALL systems
filebase files for the match and create the necessary request to
the appropriate system upon program close. The add file command is
activated by pressing "A".
- "S"ystem Select
---------------
This allows the user to select from a list of systems to request
from. The user can only be "logged on" to one system at a time.
When a system is selected, the control file, AREAS.CTL is loaded
up for that system for speed into memory. Most commands deal with
the current systems areas in mind, so to access another systems
file areas, you must select another system again. All commands
refer to the current system only except the batch editors add
command, it has a global searching mechanism.
- "G"oodbye/Logoff
----------------
This instructs BrFreq to logoff the user immediately. All
requests are cancelled and not processed as it is assumed that
if the user made such a drastic move as request to log off and
not just quit to the BBS then they must not want to send out the
existing requests.
- "F"iles Listing
---------------
This will take the user to a selection screen to select the file
area they wish to view. When they are scrolling through the
listing once they have selected their area, at the bottom of each
page full of files they receive a one line prompt with a couple of
items available to them. "Y" or Enter will simply continue on with
the listing clearing the screen first. "N" will abort the listing
and drop them back to the main menu so that they may continue with
other commands. "F"lag allows them to select a file that they see
for request. If they enter some valid input, the current file area
is rescanned to see if it was a valid filename from this list. If
it was, then it is added to the list in memory(that batch list we
talked about above) along with the system name, password etc and
the user continues on until they either reach the end of the
listing or press "N" to abort the listing.
- "?" or "H"elp
-------------
This is the help screen as specified in BRconfig under File
Requesting->Help Screen. The path and filename specified there is
the file that is shown to the user. A sample screen is included in
the distribution archive. This file can include any PCB macros you
wish to insert into it and should describe the commands available
to the user in different parts of the system.
- "Q"uit to BBS
-------------
Exits current requesting session. The user is prompted on
whether or not they wish to send out their requests, but only if
there ARE requests, otherwise the bye screen as specified in
BrConfig is shown to the user followed by the delay time as
specified in BrConfig that the system "freezes" to wait for the
user to see the screen before they are returned to the BBS.
1.6.4
- Other considerations and Setup Options/Tricks
---------------------------------------------
Any of the screens specified in BrConfig can have any of the
existing PCB @macros@ in them. They will be expanded and shown to
the user as they would appear if PCB itself had displayed the
file. Please consider using the delay feature very carefully, it
is designed to offer alot of control by allowing 1000 counts as a
second. We find a setting of about 500 with a 14400 user online is
about right but it is totally up to yourself. Also, please
remember that online speed is slightly (only slightly) slower when
there are alot of messages in the netmail area. This is not a
major problem as the messages are only scanned once upon program
startup and once afterward for request generations.
- Other Systems Requesting Files from Us
--------------------------------------
Other sysops can use BRFreq just as well as users. You now have
a two level file requesting system. Because the whole system is
based using the *.MSG netmail system, BRFreq will honor requests
from sysops who have the proper access. BRFreq only discerns on
which system the request is from. It will maintain accounting info
for these types of requests as well. The format for a request via
BRFreq is as follows...
To : BRFREQ,<Requested System>
Subject : Your TIC password already set up.
Message Text : ...
REQUEST <FILENAME> <AREANAME> -> Must have keyword REQUEST
REQUEST <FILENAME> <AREANAME> -> Must be followed by Area.
UPDATE -> Forces new lists from host.
LIST <Date> -> Should not be used.
--- -> Anything past this is ignored.
You should never use the LIST line.It has a datefield calculated
which is very hard to describe, and cannot be easily figured out.
What is does is basically pass the host system the date of its
last update from them. The host then compares the date with the
date of its last filebase update and if the number of days exceeds
the "List Delay" field value(or 0 for always), then new lists are
zipped up and sent back to the requester. This ensure that with
every request sent out, the other system is updating you with any
new changes to their filebases.
By the same token, you can force an update at any time by
entering the keyword UPDATE by itself on a line followed by a
hard carriage return(Enter);
You can also have BRUtil "Get" you a file from another system
directly from the DOS prompt. Please read info on BRUtil for more
details.
You must do a couple of things in order to allow another sysop
access to your file areas. First they must have a nodes record in
the nodes database.This nodes record should reflect the daily caps
as well as the other limits and statistical control options you
would like to have for this node. Please include a password they
can use as well as setting their security at a rate so that they
have enough security to at least see one area. It is wise to set
their delay days to zero so that they may request list updates
only as they need them.
They may also request list updates at any time without adding
the lists stats to their account. We considered adding the bytes
but opted against it as it would be unwise to debit their accounts
for lists. Only files requested will affect their account.
As with the regular user requesting system, all behavior is
similar so assuming such things as netmail laying around if that
node has exceeded their daily limit for another day is something
to consider with this end of the system as well. Once they are
in the nodes database, you can also have them downlinked (or
uplinked) to any echo area so they have total access to your
files system. For systems not running PCB, this is the only way
to use the requesting system, there is not yet any support in
BRFREQ for anything other than PCB. Becaus of this, Additional
support was an afterthought prior to release time but we intend
to extend support to all BBS types.
- System information while using BrFreq
-------------------------------------
In future versions of this package, a great deal of attention
will be paid to this end of development. We feel at this time that
it is VERY rudimentary but functional. This will have to be the
time to see what kind of reaction this type of system has and if
there is even merit for its continuation. We feel that it is a
wonderful idea and hope to have the concept around for a long
time. With this in mind, we are hoping to get some feedback as to
which way you would like this type of system to go. Ratioed
systems, "pay as you play" systems that charge per meg etc. These
are all ideas but in implementation quite a different story. With
a package of this size it is important to keep overhead down and
to keep performance up. Suggestions are welcome.
1.7.0
Using Base Runner
─────────────────
Running Base Runner is very flexible to the end user. Any or
all of Base Runners features may be disabled leaving (possibly)
only the deletions ( not age , just index ) and the filebase
updating as the core operation. This is unlikely, however as
there would be no point to that. Here we will go over some of
the command line parameters that are available to you. You may
edit your batch files if you are running on "auto pilot" to
reflect and customize your systems requirements and/or work load
In no particular order and case insensitive...
(This is also similar to the help screen)
Only first three letter of the command are required...
-Adoptions: Enables New Files Adoptions.
-Agedelete: Enables Age Deletions.
-All : Assumes all processing without Ega switch.
-Announce : Enables Announcements(+)
-Bases : Enables FileBase Generation.
-Deletions: Enables Deletion Features(Missing Files).
-Echos : Enables TIC processing.
-Ega : Disables VGA palette manipulation.
-Mgr : Enables Area Manager Operations.
-Movement : Enables Automated File Movement.
-NAs : Enables .No & .NA Processing.
-Requests : Enables PCB User Request Processing.
-Update : Enables Uplink List Processing.
-UpdateNA : Enables importing of new uplink lists.
-Uploads : Enables User Upload Processing.(+)
-Quiet : Uses stdout only, disables VGA and fancy boxes.
-Zic : Enables Inbounce Compressed TICS processing.
-? or HELP: Help Screen similiar to this.
+ = Registered feature
These commands may be used in any order and are case
insensitive. These may be helpful if you are running Base Runner
from a front end and only (perhaps) want to say, run echos but
nothing else. This makes overall performance faster because then
later on or another time you may then run it in a "complete"
processing mode which would then catch up on the overall
processing. A couple of examples are as follows...
(1.BAT)
if exist DONTSCAN.NOW del DONTSCAN.NOW
BaseRun /Ann -MGR !req
(2.BAT)
if exist DONTSCAN.NOW del DONTSCAN.NOW
BaseRun -mgr -bas -upd -mov -age -ega
(3.BAT)
if exist DONTSCAN.NOW del DONTSCAN.NOW
BaseRun
rem Assumes complete processing
(4.BAT)
if exist DONTSCAN.NOW del DONTSCAN.NOW
BaseRun -All -Ega
rem Complete processing without Vga palette manipulation. This
rem may be required for some Desqview applications.
As you can see, the prefix is not important and you can string
as many of these commands togetther as you like. The syntax is
short so that many commands may fit onto one command line, which
will hopefully offer you the flexibility you will need to get
EXACTLY the job you want done. There is a small semaphore file
created and deleted each time Base Runner is run. The line to del
this file is necessary in case you had a prior power failure or
if for some reason that file was left laying around. At the same
time, if you are not using any of these types of batch files and
for some reason your system has this semaphore file(DONTSCAN.NOW)
in the Base Runner directory, you will have to manually delete
it before Base Runner will operate properly.
You must also have a valid PCB envoironment variable set if
you want Base Runner to successfully see the PCB configuration
files. You must be in Base Runners home directory to run it or
it will not find certain "static" ques that it needs. If you do
not use the PCB options of the package, you may ignore this.
You must have at least 490K free for Base Runner to run optimally,
even though it will run in about 450K. The reason for this is
that the archivers and scanners need about 400K and with the foot-
print Base Runner leaves in memory, you are already at 450K, but
it is best to add an extra 50K for the "static ques".
For information on the actual execution and functions
performed by Base Runner, please read the section on "What does it
do?", 1.1.4.
1.7.1
Area Manager
────════────
Base Runner has a feature which allows your downlinks the abi-
lity to automatically perform various database operations via
remote(provided they know their password) netmail messages. This
is known as using the Area Manager. With this, your downlinks
simply enter a fido netmail message addressed to Base Runner on
this system, enters their password on the subject line and then
puts requests to add or delete echo areas from their current set-
up. This is done automatically by Base Runner during its normal
operation. There are a few commands available to the downlink.
They are as follows...
+AREANAME .. adds the area AREANAME.
AREANAME .. adds the area AREANAME also.
-AREANAME .. removes the area AREANAME.
%RESEND<File> .. Please see below for explanation.
%ALL .. Adds all available areas.
%LIST .. Requests a list of all available areas.
%QUERY .. Requests a list of all connected areas.
%UNLINKED .. Requests a list of all unlinked available areas.
%LINKED .. Requests a list of all linked areas.
%PASSWORD .. Changes the current password for that node.
%ARCHIVER <type>.. Changes default archiver type to type.
%TICMODE <mode> .. Changes Ticmode to mode.
%HELP .. A file called FILEMGR.HLP is put into a netmail
message and posted back to the requesting sysop.
This file can contain whatever you like and
can be edited with any plain vanilla text editor.
There is also a special kind of '%' command available to the
requesting node. This is the %RESEND macro and is basically just
what it says. Sometimes, you may find that you no longer have a
file you really wanted to keep but for some reason(age deletes
etc.) you would like to get it again. You may simply use the
resend macro along with a filename on the same line to get the
file along with the original TIC it came with. The TIC will help
you to import it normally when it comes. A note should be made
here that when the file comes back through, it does *not*
increment any of your file/byte counts, including daily counts
as it is assumed you have already received that file, therefore
the value increment would reflect an incorrect figure. As well as
as that command you also have %TICMODE and %ARCHIVER available to
you. TICMODE can be any one of these 5 settings...
- FilesOnly - Base Runner will send out files with no TIC.
- FilesandTics - Base Runner will send out both files and TICS.
- PackTics - Packs up TIC files but attaches files regularily.
- PackFilesOnly - Packs up files with no TIC attach.
- PackBoth - Packs both TICs and Files into one archive.
All one word, case insensitive(except the TICMODE command).
Also included is ARCHIVER, which can be any 3 character string
as the new archiver type. Please be sure that the system supports
type, for example "ZIP", "ARJ", "PAK" etc...
This system offers a powerful way of managing echo areas with
the greatest of ease and use. Every activity is logged and full
security checking is performed to ensure that the node is indeed
qualified to make such a request. Replies are sent back to the
originating node for all area manager requests. All request text
past a "---" , tear line, beginning on the left column of the
text, is ignored and is considered comment and/or personal text
and not to be processed any further on down the file. If a nodes
request reply is longer than 400 lines, a new continuation message
is generated and the list continues on that message. This may go
on for as long as it takes to satisfy the area manager request.
1.7.2
- What Went Wrong?
----------------
Below is a list of commonly asked questions to aid in solving
some problems you have be having. Of course support is readily
available. Please read below for more details on how to obtain
support directly from CompuData Systems.
Q. - When I try to run BRCONFIG, all I see is the intro banner and
then I am dropped back into DOS. Why won't the config program
run?
A. - You might have a corrupt resource file. This is the file
named BRCONFIG.RC. It is used primarily for the config but
it will be used by all programs soon.
Q. - I have a file area set to move files after 15 days but they
are never moved, in fact, they are not anywhere at all!
A. - Do you have age deletions set for that area with an age set
up less than the movement days? If so, make sure deletions
are set up later than movement (also good for cleanup) or
disable them altogether by setting the number of days to
zero.
Q. - When running the configuration program, all I ever get to see
is "PCBOARD.DAT file not found!".
A. - You have installed your system as a PCB system which means
that the config program now looks for your PCB envoironment
variable and reads your PCB configuration files to get info
about your system to make your work easier for you. A good
example of this is the Import File Areas function in the
file areas manager, it scans the areas not currently in
your database and shows them to you and allows you to pick
the areas you would like to configure.
Q. - I have the PCB end of things set up properly, but I still
can't run the config program.
A. - Do you run a network? If so, do you use the proper DOS
pathname or do you use the networks system for the envoir-
onment variables? Base Runner requires that you make your
network be able to read regualar DOS pathnames such as..
D:\PCB instead of the common NODE1\\C-DRIVE\\PCB. The
second example will not work and Brconfig will bark up if
confronted with these pathnames.
Q. - I have a file that just won't move, no matter what! I
have file movement for that area set up and it is long
overdue!
A. - Is the file area set up for downlinking originals or modif-
ied files? If modified files, it could be that the file is
still frozen. If a file is echoed directly from one of your
filebases, it is temporarily "frozen" while it gets mailed
out to your downlinks. Then you must run BRUTIL NOKILL to
clean the flags up on these files. Then you can see that the
movement operations will again kick in.
Q. - Base Runner seems to always want to delete files from the
outbound that aren't even sent yet!
A. - You could be set up for PCB netmail. If so, it is important
for us to know which netmail you use, 15.21 or later. They
are very different in the way the FIDOQUE.DAT file is stored
so you must have the proper one set for your PCB system or
you will have problems reading this file and might lose some
files.
Q. - In file movement I see alot of files in one area with many
different owners, why are they not all the same name?
A. - Some of them may have just got into that area. They are "in
transit" so to speak. They will get move when they have
been in that area the specified number of days. Another
thing to watch out for is "dead" links in the chain. For
example, NEWUP moves to 1-30 after 1 day and then after 30
more days they go to 30-60, then to OFFLINE. You think that
it is supposed to go to OFFLINE directly but first it has to
go to this areas destination. The problem here is that the
link between 1-30 and OFFLINE is broken because of the link
30-60. If 30-60 is not set up to properly move to another
area(the OFFLINE area must be in the path somewhere or the
file will continually move), or it is not set up at all for
movements, the files will just sit in 30-60 and not go
anywhere, so OFFLINE never sees the files. Just follow the
area chain down to the final destination point and make
sure all links are set up properly.
1.7.3
Converting from Other Formats (Convert.exe)
───────────────────────────────────────────
Base Runner offers a small utility that you may only ever need
to run once, hence the reason for it being all by itself. It is
call CONVERT.EXE and its sole purpose is to convert data files
from other programs to Base Runners format or at least as close
as we can get. It is sometimes hard to get as much information as
we need, but you will have as much information as is possible.
The reason for this is that Base Runner is much more complex and
stores more information critical to its operation than most other
programs so depending on what you are converting from, some of
the information will still have to be manually inputted. Support
includes ALLFIX. To invoke this program, simply type the program
name and a help screen will pop up with the available types.
This list is always growing and these programs constantly go
through updating so it would not be wise to try to pin down just
what is done. We will endeavor to keep up to the many versions.
When converting from other formats, you must make sure you copy
the appropriate setup files into Base Runners directory before
you proceed. This ensures the integrity of your original data
while allowing Base Runner its home directory (which it uses to
calculate home paths as defaults, etc...) to set itself up in the
most complete way. As an example, for Allfix, copy all the *.FIX
files into Base Runners directory and then from that home dir,
just type CONVERT ALLFIX and it will take care of all the echo
areas, folders(groups), nodes, system info and initializes a new
duplicate base.
We would like to make note of the fact that these programs may
change their configuration at a moments notice. We endeavor to
keep up with any changes we know about. You may, however, not
have a current Convert.Exe because the format you are converting
from has changed since the last update of the Convert program.
If this is the case, we probably already have a current copy
available. You can contact any one of the support sites to
obtain the most current copy. If we haven't yet dealt with the
current version you are running, we would appreciate any info on
the changes you might know about and/or any development text
that may be available. We can usually have the Convert program
update within a day or two of receiving such info. Please read
section on support for more details on obtaining a current copy.
1.7.4
What You Get for Registering
────────────────────────────
Base Runner comes fully functional right out of the box! There
are, however, a few added features that greatly enhance the
functionality of Base Runner which you may be interested in that
comes with registering the software. You are not expected to
register the software if you do not need access to the registered
features, but we would certainly not argue with you if you did...
Some of these features are...
1 - Automatic Uplink List Maintenance. Uplink lists are
automatically imported into the system as they come in.
2 - Upload Processing. Process and import User Uploads directly
into the filebases.
3 - New File Announcements. Have Base Runner post messages into
any message base.
4 - Access to the full command line version of the Utility
Program. Most of what that program is capable of is included
in the full screen interactive version but there are a few
differences. These are History(generate History reports),
Get (gets a file from any node from command line),
Master(builds a master list of specified file areas). All of
the others are still available in the full screen version.
5 - Auto-Add Echo areas. This feature will automatically create
areas on the fly!
6 - Archive Comment support. This is the header comment you can
insert into archives. Full macro support is also included so
that you may template any style of comment with up to the
second information right in the comment text.
7 - .NA and .NO File area description processing.
You become a supported user and can feel free to count on
support any time you need it. You have access to the support
sites for support as well as receiving a discount of %10 on your
next CompuData purchase. Please consult PRODUCTS.DOC for more
details on the continually growing line of communications
software offered by CompuData Systems.
1.7.5
Errorlevels Returned by Base Runner
───────────────────────────────────
Following is a list of returned errorlevels and what they
mean....
1 - Configuration File SYSINFO.DAT file not found.
2 - Invalid or missing Work directory.
3 - Invalid or missing Main Filebase directory.
4 - Invalid or missing Filebase Index directory.
5 - Invalid or missing FileBase Header directory.
6 - Invalid or missing FileBase Text directory.
7 - No node addresses were specified in config.
8 - Invalid or missing Inbound directory.
9 - Invalid or missing Netmail directory.
10 - Invalid or missing Header directory.
11 - Semaphore file found, active on another node.
12 - Invalid or missing Embedded Archive directory.
1.7.6
Why Use Base Runner instead of the competition?
───────────────────────────────────────────────
There are many TIC processors out there available. We won't go
into all the various types but will zero in on a couple of them
to show you just why you should use Base Runner. The ones we
will pay the most attention to are Allfix and DW_TIC (or
TIC2PCB). Please note that Base Runner has all of their features
as well as the ones below plus any new ones that have and will
be added after the printing of this document.
- Speed. Base Runner is written in Assembler and C++ programming
language. The others are written in Turbo Pascal. Pascal, while
a fine language, is just not as fast in execution as assembler
and C++ objects. Also, Pascal does not store high enough
numbers, so certain statistical information must be kept to
small numbers. This is a bit of a hinderance for some things so
you will find these authors omitting certain statistical info.
- Features. Base Runner is the only program of its kind. It is
the only program that has such a file request system available
to users as it does. NO other system offers users availability
to other BBS file areas so directly as BRFREQ does. Allfix has a
system where sysops or perhaps even users may scan for files on
other BBS's, but then what? Users cannot then request or gain
access to those systems unless they wish to call them directly,
go through their new user procedure and then perhaps gaining
access to these files. If then, this feature is only available
to the sysop who wishes to file request these files directly, no
apparent gain is extended to the user. Who do we run our BBS's
for, ourselves or our users? Base Runner breaks down that wall,
allowing your users DIRECT access to configured systems, taking
care of all aspects of moving the files from their systems to
yours, even announcing, upon arrival, these files so that users
may then download them. And this is only one of Base Runners
features... Others include ...
1. Up to 10 virus scanners.
2. Unlimited echo areas(Allfix has only 2048)
3. Unlimited nodes(Allfix has only 1024)
4. Unlimited downlinks(Allfix has only 256)
5. Up to 50 Aka's(Allfix has only 20)
6. Seperate file and echo areas(Allfix requires you to
duplicate a single file area for each echo area you
have, possibly requiring you to change MANY echo areas
in order to alter configuration for one single file
area... lame, very lame).
7. 3 different video modes of operation(Allfix - 1).
8. Up to 15 uplink lists per node(Allfix - 20 total).
9. Send file to any node anywhere, anytime.
10. Get a file from any system anytime, anywhere.
11. Full featured Util program with 2 video modes as
well as command line operation for use with events,
batches etc.
And this is only what I can think of off the top of my head(that
I can verify), there are many many others.
- Specialization. Base Runner does not try to be all things to
all people. We realize that BBS programs are very diverse. We
therefore only support both PCB and FILES.BBS systems directly.
We do not try to support 20-30 programs. This would be, in our
opinion, total overkill. That way you get some features per
system but never a complete system to deal with YOUR BBS. Pascal
having its own limitations, Allfix is tapped out on data space,
more features at this point will greatly influence its
reliability factor. We cannot make this claim in the case of
DW_TIC as it only supports PCB at this time(this may change,
however).
- Automated File Movement. Either of the other two support this
feature as they are just not designed to do such things. In
Allfixs' case, because many echo areas can include the same file
area, under its current design, it cannot even consider direct
file area support such as this, not to mention the overhead and
extra data it is storing to duplicate a single file area into
many echo areas.
- Seperate BBS and TIC layers(or file and echo areas). One of
the most inventive design implementations of Base Runner is its
use of seperate file(BBS) and echo(TIC) areas. Why would we want
to duplicate data in all those echo areas when all we want to do
is to point many echo areas to one file area? Why didn't Allfix
think of this? We don't care, we only know that if you want to
change one file area, you change only one area, not have to hunt
down all these echos that may point to the same file area to
make your changes. Plus we do not have to memorize all these
duplicate areas. We do not know how DW_TIC handles this. Some
people claim to be confused by our design but once you grasp the
obvious concept of these seperate layers, you will wonder why it
was ever designed any different.
- Direct configuration using an easy to use config program.
DW_TIC requires (as of the printing of this document) you to
manually edit a text file as its configuration system, with no
help systems, no pick list dialogs... nothing. We did things
this way 15 years ago when most of us programmers did not
concieve of the idea to do it any differently. Base Runner
provides an easy to use, flexible configuration program which
allows easy pick list dialogs for situations when you don't know
which BBS area you wish to use(for example) as well as a full
help system anywhere in the program by simply pressing F1. This
is not a feature, in our opinion, as much as it is a necessity.
When we learned that our competitors use this system, we
honestly could not believe our ears.
- Age deletions. No other system has this feature. Base Runner
can automatically delete files that are older than a certain
age.
- Empty base cleanup. Base Runner will also search through your
BBS areas and delete any filebase entries if no file exists on
disk to match that file, keeping your file areas clean. This is
totally configurable on an area per area basis, of course!
Neither Allfix or DW_TIC have this feature.
- Filebase Editor. Easy to use editor with very powerful
features, none of which are crippled. These include 2-way file
id insertion/extraction, abandon file (delete only filebase
entry), delete, view archive, information stats on current area,
move, copy etc. This is a full feature system so that you really
have no need for such programs as PcbFiler. Allfix nor DW_TIC
provide such a program nor likely ever will.
- Online door for your users(PCB only). This is as we mentioned
above, but has an online chat module plus features to hang up on
user, change security and lockout user any time you wish. It
also provides the user with commands such as "login to BBS",
"Files", "Areas", "Flag for request", "Batch editor", "Logoff
BBS" and "Exit to BBS" as well as many more being constantly
added. This system will eventually be adapted for other BBS
types, but only BBS's that support the FILES.BBS format or that
fall into our area of support. Neither Allfix or DW_TIC offer
this feature.
As you see, these are only but a few of the extra
features provided by Base Runner. Add that it is not crippled
nor has "evaluation" periods after which it just refuses to run.
Why would we let you get your whole system set up and then just
yank the cord on you? Kind of violent if you as us... ;) You are
free to run Base Runner as long as you wish free of charge. Of
course we have a few features(None of which were mentioned
here), that you get when registering(as well as free updates and
constant contact), but they are actually inconsequential when
compared to the overall scope of operation of our competitors.
1.8.0
- Strategy
────────
This section is provided to give you some ideas on good ways to
implement Base Runner. There are such a myriad of ways to run it,
but we have run into some during testing we thought we would share
with you. They are laid out in as easy to read form as possible.
We hope this will give you an idea of just how powerful this
package can be and to help you think in ways we have not even yet
imagined possible. If you have a unique setup you do not see here,
please let us know, we will put it here for others to catch.
- Simple Three Tier System
------------------------
Inbound
|
----------------------------------------------
| | | |
Games1 Games2 NODELIST Os2
| | | |
2 days week 28 days 1 day
| | | |
---------------------------------------------
|
Offline(eg. Tape Backup)
- Time is of the Essence
----------------------
Inbound
|
0-7 days
|
Move after 7 days
|
7-14 days
|
Move after 14 days(set to move "Home")
|
----------------------------------------------
| | | |
Games1 Games2 NODELIST Os2
| | | |
---------------------------------------------
|
Offline(moves nowhere)
- A variation on that Theme
-------------------------
Inbound
|
0-7 days
|
Move after 7 days
|
7-14 days
|
Move after 14 days
|
----------------------------------------------
| | | |
Games1 Games2 NODELIST Os2
| | | |
--------------- -------------
| |
| Inbound OtherNet
| |
| -----------------------------
| | | |
| Net Stuff O.Systems Request
| | | "Home"
| -------------- (no move)
| |
----------Offline------
(both nets files end up Offline)
1.8.1
- More Points Regarding File Movement
-----------------------------------
Please remember a few points when dealing with file movement.
These will help you to more fully understand the concept behind
it.
- Once files have been imported by TIC, the echo areas are no
longer considered. They are only involved as far as to setup up
an initial file areaname and an owner file areaname. After that,
file area configuration TOTALLY handles file movement, including
links.
- At any time, a file area might use the keywords HOME or
NOWHERE. HOME means that all files that are moved from this area
are automatically move to their HOME or owned area. This
ownership is first established by the field in echo areas, but
may also be edited using BREDIT. NOWHERE means that the file
area does not support movement of any kind. You may also leave
this area blank or set days to 0 for the same effect.
- Link days represent days as they stand from the date of
movement and not the file date. Hence the file date is NOT
altered during movement and all dates are still kept internal.
- Once a file is home, it stays there. This is ascertained by
matching the owner name to the area name. Even if more files
come in and there are movement characteristics setup for this
area that might include linking to another area, once a file
owner name matches its current file areaname, it is considered
out of bounds to movement. This may be edited or overriden with
BREDIT manually , of course.
- Make use of the "Trails" feature in file areas. This helps in
debugging your setup and allows you to view your current file
movement trails, showing you all areas linked BELOW this one
right to the end. Up to 700 trails can be shown at any one time.
- Remember that if you wish to leave a file in an area longer
or even shorter than it normally would, you may edit its date
using BREdit. Be sure to edit the Arrival Date and not the file
date.
- More on the last one, Base Runner keeps two dates recorded
for each file. Each time a file successfully moves to an area
the arrival date is reset to the day it is moved. Then when the
days are met from that recorded date, the file gets moved. The
actual file date on disk and in your database stays the same.
With this in mind, it is possible to have a file that is years
old but still be involved in a movement cycle.
- Unlike some other movement processors, Base Runner does not
rely on any more than a couple of fields edited once in the
config program to set up characteristics. We do not require
you to know filenames or wildcards when files are being moved.
You only need to know the area name to move the file to and the
number of days in which to move it.
1.8.2
- A Couple of Tricks - not for the faint at heart ;(
--------------------------------------------------
Automatically have Base Runner maintain your inbound directory
by setting up a file area that points to that directory and have
auto adoptions(orphans) set to "Y". Since adoptions are done
after any other file importation, it can be assumed that all
files are now processed from your inbound. If there are any
"strays" hanging around, they can then be adopted and if their
movement day is set low, they are moved out of that area. This
ensures total maintenance on your inbound directory. You will
have, of course, all the stray files to edit or delete or move
etc., so that even files that come in without TICs or just any
stray attach files come in, you have them adopted and in your
system.
Another trick feature of this type of system is to create an
echo area record to be used as a clone for the auto-adding
features of the areamgr. In this record, the trick is to put any
nodes you wish to have ALL areas added by the uplink attached to
this area. For example, BOSS sends me files and BOSS is set up
with a TEMPLATE clone area that has END as a downlink in it.
BOSS sends me an area I do not recognize so I auto add with the
new TEMPLATE area. Automatically that node is connected to this
newly created area. This is a nice way of allowing downlinks to
get "Whatever new area comes in" from you.
You can have Base Runner automatically hatch out your new
master lists. Simply set up a new echo area and make sure the
correct systems are connected to this area. Then every time you
run BRUTIL HISTORY(or any of the reports operations) you can
have your batch file then run HATCH on the master list file into
the newly created area and all the downlinks in that area
receive the file and that area records the files and Kilobytes
hatched.
1.9.0
Support
─────═══─────
Support is available from Alpha City BBS . We have a support
conference on that system that is directly tied to us.You may send
netmail (routed ONLY as we are private)to 1:229/2 to gain direct
access to CompuData
The phone number for the support BBS, Alpha City BBS is (905)579
1502 any time of the day. Just join the CompuData Message
conference or the CompuData file area to see what is the latest
on our product line.We have a continually growing line of communic-
ations products based for the PCB envoironment as well as many uti-
lities sysops and users alike would enjoy.All support is handled by
Steve Tupy of CompuData,so address any questions and/or messages to
him directly to gain the fastest access. There is also an echomail
conference called COMPUDATA available from any of the above sites.
Of course you may also call us anytime for orders or voice support
at (905)721-8944.
Please consult file REGISTER.DOC for registration information and
support. Please register if you are going to use this product, it
makes the product better all around.
Please have a look also at a file called PRODUCTS.DOC. It lists
all the available products CompuData currently has in release.
Also, we are always looking for beta testers so if you are
interested in any of these packages let us know, we are always
happy to listen!
2.0.0
Lets Hear it for our Beta Team!
───────────────────────────────
Good things come from hard work and Base Runner is no exception.
CompuData Systems would like to acknowledge the following people
for their excellent contributions. These people worked very hard
and are the people behind the lines but does not make them any
less a part of CompuData Systems and any success that it may enjoy
as a result of that work.
Base Runners Beta Team
----------------------
Ron Provost 1:229/401.0
Graham Pearson 1:2285/60.0
Joel Fiszman 1:250/669.0
John Morse 1:229/426.0
David Bate 1:229/618.0
Andrew Adams 1:229/214.0
CompuData would like to also acknowledge the following people
for their ideas and suggestions and any other help that they have
offered.
Ken Wilson 1:12/12.0
Rick Johnston 1:229/2.0
Fred German 1:229/124.0
Also, special thanks to Rick Johnston & Ron Provost for all the
late night hours of brainstorming ideas and concepts. We came up
with alot of interesting things, most of which you will see all
over this package.
David Bate has done a great job on the extra screens. We include
all 8 of them for your perusal, if only for quantity. These are all
the BRFreq screens with the "BR" as the first letters of the name.
We think you will like them very much.
There is never too much that can be said about the efforts and
determination of these people. During a time when it is hard to
get anyone to even look at a package when so many are out there,
these people all took great interest and are *very* much involved
in the overall effort!
2.0.1
Files in the distribution archive
---------------------------------
If you did not receive exactly these files in the distribution
archive, we will not gaurantee its validity. Please see section
on support sites to get the latest CompuData Systems releases.
Getting the packages from any of those sites will gaurantee you
a valid copy. Accept no substitutes! ;)
Executable Files
----------------
BASERUN.EXE - Main Program, processes all incomming files,
requests, deletions,file movement,age deletions,
adoption,auto area create,auto node create, file
manager, imports uploads, regenerates DIRs,CRC,
Dupes,Virus Scan,Comments, File id,Add file(s),
Delete file(s),Announcements. This file is su-
bject to change with new additions.
BRCONFIG.EXE - Configuration Program, allows easy interface to
setting up and running Base Runner, adopting
PCB bases etc.
BREDIT.EXE - Main Filebase editor with many added features.
File id,hatching, add files, copy, move, delete,
add,edit, datestamp,abandon,view etc.
BRUTIL.EXE - Utility program. Can be run in interactive mode
or command line mode. Pack, deletes, indexes,
hatching, notifying, dupetrim, duplicates, un-
linking,init bases etc.
BRFREQ.EXE - File requesting door for your users. Must be
installed properly via PcBoard.
INSTALL.EXE - Installation program.
CONVERT.EXE - Conversion program will convert existing programs
config files over to a Base Runner format.
Sample Files
------------
MSG.TXT - Sample message text to insert for announcements.
Includes some macros which are supported.
MAING - Ansi of main menu for BRFREQ. Very simple.
BRMAIN - Another sample, a little brighter.
INTROG - Logo or intro screen for BRFREQ.
BRINTRO - Yet another Intro screen.
BYEG - Screen shown to users upon exiting BRFreq.
BRBYE - Also screen for exiting BRFreq.
BRHELP - Help screen for activate of "H"elp command.
BRFREQ.HLP - Just another version of the same screen.
COMMENT.TXT - Text for comments with full macro support.
FOOTER.PCB - Example footer for insertion in DIR files. These
files should be kept in the HEADERS directory.
HEADER.PCB - Example header for insertion in DIR files. These
files should be kept in the header directory.
BRFREQ - Sample batch file for BrFreq for use with PcBoard.
RUNBR.BAT - Sample batch file for running Base Runner.
Help System Files
-----------------
BASERUN.HLP - Main help text file, indexed, do NOT modify.
BASERUN.IDX - Index for BASERUN.HLP. Must be in home directory.
BRCONFIG.RC - Resource file containing menus and string tables.
Documentation Files
-------------------
PRODUCTS.DOC - Available CompuData products as of the compila-
tion of this document. It grows all the time.
REGISTER.DOC - Registration information. Here you will also
find a printable registration form you may send
in with your registration payment.
BASERUN.DOC - This main documentation and reference point for
Base Runner(this file).
README.DOC - Introduction and installation notes.
2.0.2
Database Files Maintained by Base Runner
----------------------------------------
FAREAS.DAT - File areas database.
FECHO.DAT - Echo areas database.
NODES.DAT - Nodes database.
HISTORY.DAT - History and User Cue database.
ARCHIVE.DAT - Archiver definitions.
FOLDERS.DAT - Folders database(or groups).
SYSINFO.DAT - Main system configuration and paths.
DIRWRITE.$$$ - List of areanames in PCBDIR/FILES.BBS Queue.
End of Document.